14

I've googled this a lot. Most of these issues are caused by a lock being left around after a JVM crash. This is not my case.

I have an index with multiple readers and writers. I'm am trying to do a mass index update (delete and add -- that's how lucene does updates). I'm using solr's embedded server (org.apache.solr.client.solrj.embedded.EmbeddedSolrServer). Other writers are using the remote, non-streaming server (org.apache.solr.client.solrj.impl.CommonsHttpSolrServer).

I kick off this mass update, it runs fine for a while, then dies with a

Caused by: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/.../lucene-ff783c5d8800fd9722a95494d07d7e37-write.lock

I've adjusted my lock timeouts in solrconfig.xml

<writeLockTimeout>20000</writeLockTimeout>
<commitLockTimeout>10000</commitLockTimeout>

I'm about to start reading the lucene code to figure this out. Any help so I don't have to do this would be great!

EDIT: All my updates go through the following code (Scala):

val req = new UpdateRequest
req.setAction(AbstractUpdateRequest.ACTION.COMMIT, false, false)
req.add(docs)

val rsp = req.process(solrServer)

solrServer is an instance of org.apache.solr.client.solrj.impl.CommonsHttpSolrServer, org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer, or org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.

ANOTHER EDIT: I stopped using EmbeddedSolrServer and it works now. I have two separate processes that update the solr search index:

1) Servlet 2) Command line tool

The command line tool was using the EmbeddedSolrServer and it would eventually crash with the LockObtainFailedException. When I started using StreamingUpdateSolrServer, the problems went away.

I'm still a little confused that the EmbeddedSolrServer would work at all. Can someone explain this. I thought that it would play nice with the Servlet process and they would wait while the other is writing.

three-cups
  • 4,375
  • 3
  • 31
  • 41
  • How are you doing the update? You know that the writer keeps the lock as long as it's alive, so if you want to swap writers you'll have to close the first then open the second, right? – Xodarap Mar 17 '11 at 20:20
  • I'll double check. I think I'm updating 256 at a time in the mass-update process. – three-cups Mar 17 '11 at 22:06

2 Answers2

14

I'm assuming that you're doing something like:

writer1.writeSomeStuff();
writer2.writeSomeStuff();  // this one doesn't write

The reason this won't work is because the writer stays open unless you close it. So writer1 writes and holds on to the lock, even after it's done writing. (Once a writer gets a lock, it never releases until it's destroyed.) writer2 can't get the lock, since writer1 is still holding onto it, so it throws a LockObtainFailedException.

If you want to use two writers, you'd need to do something like:

writer1.writeSomeStuff();
writer1.close();
writer2.open();
writer2.writeSomeStuff();
writer2.close();

Since you can only have one writer open at a time, this pretty much negates any benefit you would get from using multiple writers. (It's actually much worse to open and close them all the time since you'll be constantly paying a warmup penalty.)

So the answer to what I suspect is your underlying question is: don't use multiple writers. Use a single writer with multiple threads accessing it (IndexWriter is thread safe). If you're connecting to Solr via REST or some other HTTP API, a single Solr writer should be able to handle many requests.

I'm not sure what your use case is, but another possible answer is to see Solr's Recommendations for managing multiple indices. Particularly the ability to hot-swap cores might be of interest.

Xodarap
  • 11,581
  • 11
  • 56
  • 94
  • Thanks, I'll have a look at how I'm using the writers. I am using a MultiCore setup. I've got a several webapps that write to the index and a separate process that is trying to update every record in the index (there are over 1 million documents in the index). – three-cups Mar 18 '11 at 02:53
  • I'm not sure your answer works for me since I'm using org.apache.solr.client.solrj.SolrServer for all my updates. (See my edited question.) – three-cups Mar 18 '11 at 03:08
  • @three_cups_of_java: But you have multiple Solr servers writing to the same location, right? My point is that this can't work - you should just share a single server. – Xodarap Mar 18 '11 at 17:25
  • Okay, I think I'm figuring it out. I just assumed I could have a solr server running in a servlet container and another solr server running in a separate process. I'll investigate this and get back to you. – three-cups Mar 18 '11 at 17:37
7

>> But you have multiple Solr servers writing to the same location, right?

No, wrong. Solr is using the Lucene libraries and it is stated in "Lucene in Action" * that there can only be one process/thread writing to the index at a time. That is why the writer takes a lock.

Your concurrent processes that are trying to write could, perhaps, check for the org.apache.lucene.store.LockObtainFailedException exception when instantiating the writer.

You could, for instance, put the process that instantiates writer2 in a waiting loop to wait until the active writing process finishes and issues writer1.close(); which will then release the lock and make the Lucene index available for writing again. Alternatively, you could have multiple Lucene indexes (in different locations) being written to concurrently and when doing a search you would need to search through all of them.

*  "In order to enforce a single writer at a time, which means an IndexWriter or an IndexReader doing deletions or changing norms, Lucene uses a file-based lock: If the lock file (write.lock, by default) exists in your index directory, a writer currently has the index open. Any attempt to create another writer on the same index will hit a LockObtainFailedException. This is a vital protection mechanism, because if two writers are accidentally created on a single index, it will very quickly lead to index corruption."

Section 2.11.3, Lucene in Action, Second Edition, Michael McCandless, Erik Hatcher, and Otis Gospodnetić, 2010

trouble
  • 71
  • 1
  • 2