Ah thanks - I was going by that comment :-)
On Mon, Jan 18, 2010 at 12:07 PM, Mark Miller <markrmil...@gmail.com> wrote: > Mark Miller wrote: >> Yonik Seeley wrote: >> >>> On Mon, Jan 18, 2010 at 1:17 AM, Chris Hostetter >>> <hossman_luc...@fucit.org> wrote: >>> >>> >>>> : Right... for stock Solr usage (i.e. as long as they don't try to lock >>>> : the same thing.) >>>> : It is funny that native locks always work across different processes, >>>> : but not always in the same JVM though. >>>> >>>> Actaully, the more i think about this the less i understand it ... why >>>> don't native locks "work" within the same VM? ... and by "work" i mean why >>>> didn't he just get a lock timeout error? >>>> >>>> >>> Within the same VM, you need the same FileChannel for some reason. >>> Lucene uses a static hashmap so that multiple NativeFSLockFactory >>> instances will end up using the same FileChannel for locking. But >>> multiple webapps obviously breaks that. >>> >>> -Yonik >>> http://www.lucidimagination.com >>> >>> >> Native Locks are obtained at the JVM level - so if you try and lock the >> same Channel twice, since the same JVM already has the lock, its granted >> again. I don't think it matters if its the same FileChannel or not - you >> just can't use Native Locks within the same JVM, as the lock is held by >> the JVM - they are per process - so Lucene does its own little static >> map stuff to lock within JVM (simple in memory lock tracking) and uses >> the actual Native Lock for multiple JVMs (which is all its good for - >> process granularity). But obviously, the in memory locking doesn't work >> across webapps. >> >> > Also, the javadocs in Lucene are wrong: > > /* > * The javadocs for FileChannel state that you should have > * a single instance of a FileChannel (per JVM) for all > * locking against a given file. To ensure this, we have > * a single (static) HashSet that contains the file paths > * of all currently locked locks. This protects against > * possible cases where different Directory instances in > * one JVM (each with their own NativeFSLockFactory > * instance) have set the same lock dir and lock prefix. > */ > > The javadocs for FileChannel don't say this at all - and this implies > that Lucene is doing something that it is not. The javadocs say don't > expect native locks to work for locking within a JVM, because it > doesn't. And Lucene doesn't try and use the same FileChannel per JVM (it > wouldn't help anyway) - Lucene simply attempts to track per JVM locks in > a static map (which doesn't work per JVM when you are dealing with > different classloaders). > > -- > - Mark > > http://www.lucidimagination.com > > > >
