Examine.AzureDirectory status

[Jeavon]

trafficstars

Wondering what the status of the Examine.AzureDirectory project is? There is a still a significant need for this project for Umbraco projects that have large index sets that are running on Azure Web Apps.

[Shazwazza]

I would love to have time to continue to pursue this but I just don't. I have fixed several issues with the original Azure Directory implementation in this codebase (I still need to re-submit PRs back to the original Azure Directory project because the code defo has bugs).

The latest status of this was:

• Updated the directory to use simple file locks because the original implementation trying to use blob storage leases as a locking mechanism has some issues
• Was looking at re-implementing the lock leasing strategy from scratch to make sure it didn't have issues

IIRC, it was the locking parts that were remaining and then testing. There's actually lock testing code in the Lucene.Net codebase even for 2.9.x which should definitely be used. We'd also need to determine if blob lease locking is even worth doing or if just sticking with simple file locks is better. ... In fact in recent versions of Umbraco (7.8+) we're no longer using the Native FS file locks with Lucene/Examine/Umbraco because this has it's own problems if the IIS process is terminated unexpectedly, then lucene file locks will remain locked by the OS. In 7.8+ we also use something called MainDom to control accessing the index (it's the same thing we use for accessing the xml cache file) and because of that, we now use simple file locking in Lucene since this is less error prone and we are gauranteeing that only a single thread is accessing the index at one time - so IMO I think a simple file lock mechanism for this would be fine.

I've also come across this project which looks interesting but does have limitations and would need to back ported to lucene 2.9.x https://github.com/MahyTim/LuceneNetSqlDirectory