Lucene.Net.Store.LockObtainFailedException after using SuggestionQuery

1,243 views
Skip to first unread message

mike....@microgroove.com

unread,
Jun 26, 2013, 1:03:59 PM6/26/13
to rav...@googlegroups.com
Having just made use of SuggestionQuery in my app, I now see a new directory called Raven-Suggestions in my db's indexes directory. I am only querying for suggestions on two properties of one index - (using two different queries). I see a handful of "Lock obtain timed out:" errors in my logs every day for the indexes in Raven-Suggestions. The D: drive is two AWS EBS volumes each with 500 provisioned IOPS striped in RAID0. Could disk IO be under spec'd? The Raven-Suggestions indexes completed eventually. Are these exceptions anything to be concerned about? Why don't these secret indexes show up in the stale stats in the studio? Here is the exception.

MY_INDEX_NAME Lucene.Net.Store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@D:\Database2375\Databases\MY_DATABASE_NAME\Indexes\Raven-Suggestions\MY_INDEX_NAME\MY_FIELD_NAME-Levenshtein-0.4\write.lock
   at Lucene.Net.Store.Lock.Obtain(Int64 lockWaitTimeout) in c:\Work\lucene.net\src\core\Store\Lock.cs:line 83
   at Lucene.Net.Index.IndexWriter.Init(Directory d, Analyzer a, Boolean create, IndexDeletionPolicy deletionPolicy, Int32 maxFieldLength, IndexingChain indexingChain, IndexCommit commit) in c:\Work\lucene.net\src\core\Index\IndexWriter.cs:line 1228
   at Lucene.Net.Index.IndexWriter.Init(Directory d, Analyzer a, IndexDeletionPolicy deletionPolicy, Int32 maxFieldLength, IndexingChain indexingChain, IndexCommit commit) in c:\Work\lucene.net\src\core\Index\IndexWriter.cs:line 1203
   at Lucene.Net.Index.IndexWriter..ctor(Directory d, Analyzer a, MaxFieldLength mfl) in c:\Work\lucene.net\src\core\Index\IndexWriter.cs:line 5441
   at SpellChecker.Net.Search.Spell.SpellChecker.IndexDictionary(IDictionary dict, Int32 mergeFactor, Int32 ramMB, CancellationToken token) in c:\Builds\RavenDB-Stable\Raven.Database\Imports\Lucene.Net\SpellChecker\SpellChecker.cs:line 405
   at SpellChecker.Net.Search.Spell.SpellChecker.IndexDictionary(IDictionary dict, CancellationToken token) in c:\Builds\RavenDB-Stable\Raven.Database\Imports\Lucene.Net\SpellChecker\SpellChecker.cs:line 446
   at Raven.Database.Queries.SuggestionQueryIndexExtension.OnDocumentsIndexed(IEnumerable`1 documents, Analyzer searchAnalyzer) in c:\Builds\RavenDB-Stable\Raven.Database\Queries\SuggestionQueryIndexExtension.cs:line 104
   at Raven.Database.Indexing.Index.Write(Func`4 action) in c:\Builds\RavenDB-Stable\Raven.Database\Indexing\Index.cs:line 347 6/26/2013 4:48:23 PM

Oren Eini (Ayende Rahien)

unread,
Jun 26, 2013, 3:50:01 PM6/26/13
to ravendb
Did you add the suggestion hint in the index creation time?


--
You received this message because you are subscribed to the Google Groups "ravendb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ravendb+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

mike....@microgroove.com

unread,
Jun 26, 2013, 4:53:09 PM6/26/13
to rav...@googlegroups.com
No, should I have? I just followed the documentation here http://ravendb.net/docs/2.0/client-api/querying/static-indexes/suggestions, doesn't mention anything about adding the suggestion hint in the index creation time.

mike....@microgroove.com

unread,
Jun 27, 2013, 2:41:06 PM6/27/13
to rav...@googlegroups.com
This is a bigger issue for me than I first thought because the Lock Timeout errors on the Suggestions index are being counted against the original index that contains the field for which the suggestions apply. If that count reaches 50, don't I have to reset the original index, and wait for it to rebuild? I have some very large indexes that take double figures in hours to rebuild, so lock timeouts on those suggestions - a secondary feature for me - are very inopportune. My conclusion is that this feature is too risky for me to make use of in production, a bit like LoadDocument<>().

Oren Eini (Ayende Rahien)

unread,
Jun 28, 2013, 6:05:56 AM6/28/13
to ravendb
Hi,
You need to look at the index definition
Suggest(x=>x.Name, ....)

This means that we will build the suggestions along the way, instead of on the first suggestion

Oren Eini (Ayende Rahien)

unread,
Jun 28, 2013, 6:06:43 AM6/28/13
to ravendb
The problem is probably that you have a large index and you are trying to create suggestions without setting the index to that.
It works for small indexes, but would generate locks for larger indexes.
See the preivous mail about how to set it up

mike....@microgroove.com

unread,
Jul 3, 2013, 3:24:04 PM7/3/13
to rav...@googlegroups.com
I have created the suggestion in the index definition as you described but it has not made any difference - I continue to get 'Lock obtain timed out' errors on the suggestions index. 

It is disappointing to read another response fitting the trend - works for small indexes, might be problematic for large ones. Slow down on the feature additions in favor of stability - please! With RavenDB you have created a very impressive feature set in a very short time. I really want this to be a success story for you guys, and for everyone who uses it. You deserve it. I detect a disillusionment backlash is setting in though for a number of users as their projects reach the size where certain features breakdown and RavenDB becomes a burden and resented. I wish I had not believed the hype regarding Map Reduce, LoadDocument<>() or Suggestions. Which leaves me with persisted pocos & lucene - which I could have done in other ways using more established software choices. If I could switch to something else now I would, but my project budget and time constraints will not allow it. So we are stuck with each other. It's not cool.

Oren Eini (Ayende Rahien)

unread,
Jul 4, 2013, 3:21:28 AM7/4/13
to ravendb
Mike,
LoadDocument issue will be resolved in 3.0 - by the time it was discovered, it was already too late in the 2.5 pipeline.
I am not aware of anything about Map/Reduce that is problematic. We have spent a lot of time and effort to make sure that at very high scale, you can get map/reduce working very nicely.
Regarding suggestions - there is a way to handle this, which won't have any of the issue you have run into, and won't have any problems with large indexes.
Yes, the way we started with is flawed, but we are somewhat stuck with it because of backward compatibility concerns. It will be something that we'll address in 3.0 by returning an error if you haven't specified it upfront.

Josh Norris

unread,
Sep 9, 2013, 7:19:25 PM9/9/13
to rav...@googlegroups.com
Would it be possible to add a flag to the config file that could just disable suggestions entirely? I'm experiencing a similar problem. I have no desire or interest in the suggestions, but they keep getting built. I believe this happens because when you query the studio it automatically does suggestions if it doesn't match any documents. It's frustrating and annoying that indexing just starts failing because of a feature that I'm not interested gets triggered by a tool that I need to use. Either that, or update the studio to not offer the suggestions in the first place. Seems like it would be pretty straightforward to just return empty suggestions if the configuration for the server blocks them.

Just a "suggestion".

Thanks,

Oren Eini (Ayende Rahien)

unread,
Sep 11, 2013, 3:38:28 AM9/11/13
to ravendb


--
You received this message because you are subscribed to the Google Groups "RavenDB - 2nd generation document database" group.

brett...@sportscstr.com

unread,
Mar 5, 2014, 2:44:36 PM3/5/14
to rav...@googlegroups.com
Did this fix make it into the newly released 2.5, or is it in 3,0?
Thanks

Oren Eini (Ayende Rahien)

unread,
Mar 6, 2014, 3:11:55 AM3/6/14
to ravendb
2.5

 RavenDB Conference

Oren Eini

CEO

Mobile: + 972-52-548-6969

Office:  + 972-4-674-7811

Fax:      + 972-153-4622-7811




Reply all
Reply to author
Forward
0 new messages