lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cowan <>
Subject Threads locking around getFSDirectory
Date Tue, 04 Oct 2005 22:15:34 GMT
Lucene users,

We run an EJB search application that has been experiencing some locking
issues. By taking thread dumps when the jvm seems to be frozen, many threads
in the application are locked around calls to getFSDirectory.

"Thread-84" daemon prio=1 tid=0x053117b0 nid=0x2274 waiting for monitor
entry [4666000..466686c]
- waiting to lock <0x4d3a86a0> (a

Details about our app:
We run inside JBoss 4.0.0
Sun JDK 1.4.2
Lucene 1.4.3
Compound Index Format
Red Hat Linux 3

Our initial research into the problem only brought up comments around
performance improvements made to lucene last year that are present in
version 1.4.3. We're wondering if the lucene user community can give any
advice for pursuing this further. Some questions we have are:

How many IndexSearchers do people usually use in their applications?
- In previous lucene versions, we found we had better concurrency using
multiple IndexSearchers
- Our current app uses an separate IndexSearcher for each thread (as needed)
from a pool

We've seen reports that the multi file indexes offer a faster search. Are
there any performance numbers around on concurrency with the multifile index
format? It seems like this could either improve or further increase
contention with locking depending on what our problem is.

Some of our searching around this problem revealed some work on something
using the java nio package.... NioFSDirectory that offered better
concurrency (
We haven't found this in the lucene repository... where or is this available
for use?

Thanks in advance.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message