[hibernate-dev] [HSEARCH] Lucene lock problems with Hibernate Search 4.0

[Sanne Grinovero]

Hi Guillaume,
thanks, good observations and I share the idea to make it as easy as
possible out of the box, but I'm not sure about what is our best
option to provide that.

First, regarding your statement of considering older versions: the
locking options I've mentioned are not new in 4.0, so this is no new
complexity even if you where not aware of it; early versions would
pick one for you, in 3.3/3.4 we introduced options to force your
choice. I'm only mentioning those to make sure you know your options,
assuming you're doing some "advanced" stuff and not really in the
standard start/play/restart dev cycle.
The only difference is that exclusive indexing is enabled by default,
while previously it was "just" strongly recommended.

I would assume that the newcomer/average developer would playing at
dev time with RAMDirectory, hence having no problem at all since we
default to "single" instance locking for memory based directories. If
you or anyone playing with is needs the FSDirectory, I'd assume either
of two reasons:

 1) Need to test with same-as-production configuration. Obviously in
this case you would use the high performance exclusive indexing set to
"true" (now default) as well, as it's extremely good for performance
and there's no reason to not use it (in production) unless you have
some fancy index sharing setup.

 2) Need to test with rather large or pre-filled indexes, hence not
wanting to rebuild the index at each step. In this case the index
needs protection - hence avoiding locks doesn't look like a sane
option - as otherwise you might get very inconsistent and confusing
results: a corrupted index might not be noticed: it's likely going to
throw errors pretty soon but there is no guarantee for a clean
fail-fast error.

What are you suggesting we should do in practice? As I mentioned in
previous mail, a stale lock means some test didn't clean up properly
after itself, so you might have as well problems with background
threads working, memory leaks, classloader problems, a lot of nasty
things: avoiding the lock by default is just going to remove the
obvious symptom of a shutdown problem, and possibly creating more
subtle issues.

What do you mean exactly with "hot replace + terminate" ? Wouldn't you
prefer using a RAMDirectory for such development?
Also consider that when changing index mapping, adjusting Analyzer
options, etcetera etcetera one should rebuild the index to have it
properly updated.

I agree this locking stuff is a PITA, I'm just saying changing this
option is not looking like it would solve the real problem, some
ideas:
 1 - https://hibernate.onjira.com/browse/HSEARCH-998 ? Rather unsafe
as it doesn't address my concerns about failed shutdown as explained
above.
 2 - register a JVM shutdown hook - no guarantees on kill, and needs
to be disabled when run in a container (hence would likely not be
enabled by default, user needs to select it) - also doesn't help with
testsuites as JVM is not exiting (this is likely a positive point).
 3 - default to "native" locks in more cases. This "native" used to be
troublesome on some OSes as documented by Lucene's javadoc, but I'm
definitely implementing this one, as I just noticed this is no longer
the case with latest versions:
https://hibernate.onjira.com/browse/HSEARCH-1022

other suggestions very welcome!

Cheers,
Sanne



On 30 December 2011 12:11, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi Sanne,
>
> On Fri, Dec 30, 2011 at 2:12 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
>> [very detailed explanation]
>
> Thanks for taking the time to answer.
>
> While I agree with you on most of what you explained, I think the
> point is: is it a good default value?.
>
> The typical development workflow of Debug mode / Play as long as you
> can / Hot replace failed / Terminate / Let's play again, which is
> quite common amongst Java developers, is clearly incompatible with the
> default values, as proved by our last week of pain.
>
> While I think most of the people going live with Hibernate Search
> would take a look at a "Before going live" section of the
> documentation, I'm pretty sure most of the developers who simply want
> to evaluate it won't read a "Hey, if you want to play with it, you
> have to be careful and change the default lock mode" section. And lock
> problems in your typical dev workflow really make you reconsider
> playing with it further - even if it's a good thing to have something
> robust in production.
>
> I seriously considered going back to Hibernate 3.6/Hibernate Search
> 3.4 on our current project before reading the code of the various lock
> implementations and thinking about changing the lock mode.
>
> Just my 2 cents as a long time Hibernate Search user and advocate (and
> a happy one).
>
> --
> Guillaume