I’ve been working in Sitecore for probably half a decade now (hmmm, really Aidan?) and until the last couple of weeks I have never come across this problem. And now I feel like I’m picking at a scab by being proactive in dealing with it.

You see, when Lucene writes to an index it creates a little .lock file so that no other pushy little processes can come along and try to write at the same time. And where does it put this lock file? You would think putting it in the index folder might make sense. If you didn’t, you should have because that’s where I think it should go. But I’ll give the Lucene developers the benefit of the doubt because in matters related to computer science I’d put money on them to smack me down in a fair fight.

So where does it go? Well, C:\Windows\Temp of course!

On my machine I didn’t have access to this folder. Our IT department rightly believes giving non-administrator users access to the Windows folder a bit of a.. risk. So when Lucene crashed the other day I had quite a bit of trouble getting at those pesky little lock files to remove them.

While I had a friendly email exchange with IT to open up temp folder access for me. I came across the Lucene.Net.lockdir app setting. Great, thinks I, and says to me self, “we’ll just set this to somewhere app-local, such as my App_Data folder that contains the indexes”.

But ’twas not to be so simple! After a few too many hours testing the various path combinations I wanted to use and blindly ignoring the posts I’d already read on the subject, I had finally satisfied myself that I now understood what this setting could do… and it’s quite simple:

You can only use an absolute local path

That means no relative paths, no ~/App_Data/indexes, no UNC paths to share folders. Just a plain old simple C:\yada yada yada\put my temp files here\ type of folder path.

I’d really prefer not to have to manage file system permissions for my app at another location, particularly in C:\Windows, but it means I now have to manage folder paths across my environments. It’s quite a trade off, because now I’m more likely to have problems setting up a new environment. Or, God forbid, another developer setting up their environment and troubleshooting the app when they’re not familiar with it.

What makes matters worse is the problem is not obvious to begin with.

When there are problems with the lockdir, you’re Sitecore application isn’t going to start up properly. And you don’t get a message, there’s nothing in the logs – it just hangs.

And boy can it take a while before you know whether it’s just a slow start-up or whether it is proper fucked. It’ll hang when you hit your front-end site, it’ll hang when you try to log into Content Editor. You can actually access the /sitecore/login page (hooray!), and perhaps if your front-end site doesn’t use Lucene you may be able to get to that also. But that’s your message – hang.

So next time you’re hanging about staring as your Sitecore app starts up.. just double check your Lucene folders. Check the path and check for the .lock files. It could just stop you having that psychotic episode on the way home from work.

Tagged , , ,

One thought on “Lucene.Net.lockdir

  1. Tim says:

    Dear Aidan,

    “Or, God forbid, another developer setting up their environment and troubleshooting the app when their not familiar with it.”

    That just happened… Luckily found your blog post 🙂

    Waiting patiently,
    Tim (another unfamiliar developer)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: