Problems with Lucene.Net and I / O Threading

I have an indexing function called "Execute ()", using IndexWriter to index the contents of my site. It works fine if I just called it from a webpage but couldn't when I have it as a delegate parameter in System.Threading.Thread. Strange, however, it always works on my local development computer, it only fails when I boot to the shared host.

This is the error message I received

"Lock commit: SimpleFSLock error ...."

Below is the failed code (but only a failure on the shared host)

Scheduler scheduler = new Scheduler(); System.Threading.Thread schedulerThread = new System.Threading.Thread(scheduler.Execute); 

Below is the code that works (it works both on my local computer and on the shared host)

 Scheduler scheduler = new Scheduler(); schedulre.Execute(); 

Now, as one of ppl said, this may be a bad result after a previous debugging session, so before I created the IndexWriter instance, I did

 if (IndexReader.IsLocked(indexingFolder)) { log.Debug("it is locked"); IndexReader.Unlock(FSDirectory.GetDirectory(indexingFolder)); } else { log.Debug("it is not locked"); } 

and guess what? my journal says it is not blocked.

So now I'm sure that this is caused by System.Thread.Threading, but I just don't know how to fix it.

thanks

+6
multithreading lucene
source share
4 answers

Make sure that on the shared host the thread has the same permissions on the index folder as on the developer's computer / shared host.

Update:. You may find that the Principal thread is running under a CurrentPrincipal thread CurrentPrincipal . Although this is a read and write property, you may not have permission to set this property in a shared host environment.

You can find this post .

+4
source share

Thanks to everyone and especially Vinay for pointing me in the right direction. After long traces, I finally decided to look at the source and see what was there.

In the "IndexWriter" you have

  Lock @lock = this.directory.MakeLock("write.lock"); if ( !@lock.Obtain (this.writeLockTimeout)) 

which points to the implementation of SimpleFSLock. The culprit was

 new FileStream(this.lockFile.FullName, FileMode.CreateNew).Close(); 

creating a new thread, internally it throws a system.unauthorizedaccessexception, according to msdn here

When starting a new thread, System.Security.Principal.WindowsIdentity.GetCurrent () returns a process identifier, not necessarily the identity of a code called Thread.Start (). This is important to remember when running asynchronous delegates or threads in an impersonal ASP.NET thread.

If you are in ASP.NET and want the new thread to start with impersonated WindowsIdentity, pass WindowsIdentity to the ThreadStart method. Once in the ThreadStart method, call WindowsIdentity.Impersonate ().

Thus, I solved my problem by personifying the IIS account running my application in the "Execute ()" function, and all problems were resolved.

Thanks again.

+2
source share

Probably the worst one to try to answer this question since I have not used lucene / shared hosting, but SimpleFSLock sounds like it is locking the lucene index file using an explicit lock file on the file system (not quite the same as locking on a thread ) I would say check to make sure that you have configured the correct file paths and the file permissions are set correctly.

Otherwise, hopefully someone more familiar with Lucene.net can respond.

0
source share

I believe the problem is with the write lock file in the Lucene index directory. Browse and list the directory files. In Java Lucene, you would see a file called write.lock in the index directory that the index was not properly closed for the last time (perhaps the process was suddenly stopped). In Lucene.net, find a similar empty file. I believe the same mechanism will be used at Lucene.net. Try to find this file, erase it and restart Lucene.net.

0
source share

All Articles