Write Lock

[ZookiniJim]

Almost every time when I debug my project I get a write lock.
For example:
I start a new project finish up my Kaliko cms installation, implement my website.
And when I start debugging the first time it's all fine, but when I make some small changes and try to debug again I get a write lock, so I stop the debugging and restart the debugging and there is no write lock.
This problem repeats it self every time.
Note: My colleague never has this write lock, even with the exact same files as me.

[fschultz]

The search engine write lock should be lifted at startup unless another process is accessing the write.lock file at the same time.

It's strange that it only seems to occur every second time only. And that your colleague doesn't get the same result using the same files.

Haven't experienced this error myself, but hopefully we might track this down.

Are you running the project through IIS or IIS Express?

When you do the changes do you stop the debug mode and then make the changes or do you make them after pausing the debug session?

[ZookiniJim]

Hi Fredrik,
Thankyou for your quick reply.
I'm running on the project trough IIS Express and I always stop the debug mode when I am making changes to the project.
Kind regards Jimmy

[fschultz]

It would be interesting to know which process locks the file. One way to find out is to run Process Explorer then hit Ctrl + F and search for write.lock when the site can't start because something is holding the file.

I've tried to search around for any information about this problem concerning Lucene, but unfortunately not found anything that applies. The IIS Express process that normally locks the file should be terminated when the debug mode is stopped. Do you have any anti-virus program that might lock the file while run-time scanning?

[fschultz]

Hi! Just wanted to check back to hear if you managed to track down the write lock?

Best regards,
Fredrik

[ZookiniJim]

Hi Fredrik,
First of all I would like to apologize for my slow reaction, I was rather busy with some projects.
But I tried to search for the process which locks the file, but I couldn't find anything.
https://gyazo.com/d7e4d0db55d1f10843389638b1a289eb
A image with the search result.
I also tried to disable my antivirus, but it didn't solve the write lock.
Kind regards,
Jimmy

[EdSF]

Unsure if this IIS Express issue is related. I don't experience the above, but am on the "lookout" for "strange" debugging session issues (like the one described in the link) that maybe due to IIS not shutting down a prior debugging session.

See if shutting down IIS Express explicitly/completely as described in the link resolves things (re: "only occurs on 2nd time...")

Hth...

[fschultz]

This sounds like a very likely candidate. Thanks for sharing the information!

[EdSF]

Cool :)

BTW, sort of "piggy-backing" on this topic of write.lock

Being a n00b on Lucene (Kaliko Search) and learning it essentially uses file system for it's index(es), an interesting read in a web farm scenario...

Have you dealt with this? Say, web server nodes where files are replicated by DFS (e.g. "somewhere else" instead of App_Data - default setting for index)?

[fschultz]

Thanks for the interesting post! I haven't any experience using Lucene in such a scenario, but spontaneously it feels like it wouldn't be totally trouble-free.

I like Lucene for the ease of setup, but it feels like the file system approach sets some limits.

In most cases during more complex solutions I've worked with the search engine of choice has been Elasticsearch (which is based on Lucene but offers a whole lot of additional values such as clustering and incredible performance). It has a nice library called NEST for use with .net.

I've thought of writing a search provider for it as an alternative to the Lucene-based, but unfortunately haven't gotten around to it yet.

[EdSF]

Old-ish post but did run into this issue today with a hosting provider (does not manifest locally) re: errors out with access issues due to "another process" to the App_Data/SearchIndex/KalikoCMS/write.lock file.

My current fix (am still monitoring), and this is probably hosting provider specific(?), was to add impersonation to my app. Account must be able to RWX (read, write, execute)

Otherwise Alas no joy, have to "disable" Search (remove web.config settings and associated calls in code)...

Hth

[fschultz]

I'll take a look at the search provider code to see if it's possible to minimize the write lock in order to reduce the risk for collisions between processes. Hope to have an update on the subject soon.

[fschultz]

This is somewhat experimental at the moment, but I've uploaded a new package over at https://nuget.kaliko.com/ of KalikoCMS.Search version 1.1.1-beta if you wish to give it a try.

I've rewritten parts of the Lucene-based code in an effort to reduce the write locks to a bare minimum. And the initial tests seems very positive. There's a small performance hit when updating the whole index, but it's barely noticeable on a normal sized website. Performance of searches should be unaffected.

The lock-down window is now so small that the write.lock file doesn't even appear in the Windows Explorer folder while performing multiple writes. I really hope this will help to solve the issue that you've encountered.

[EdSF]

Cool beans - will do. I plan to load that up into a new project and test in a real hosting environment where I have no idea what the configuration of the servers, storage, etc. are - - and hopefully adds to the collective "experience" of those using this cool CMS :)