Hello, I have looked a little further, this Lucene issue is related to it:
https://issues.apache.org/jira/browse/LUCENE-743 They did change quite a bit regarding ref counting in lucene from 2.2.0 to 2.3.0. In the lucene multiReader the doClose() changed from: protected synchronized void doClose() throws IOException { for (int i = 0; i < subReaders.length; i++) subReaders[i].close(); } to protected synchronized void doClose() throws IOException { for (int i = 0; i < subReaders.length; i++) { if (decrefOnClose[i]) { subReaders[i].decRef(); } else { subReaders[i].close(); } } } Also Lucene IndexReader mechanism regarding when pending changes are added to the index have changed (only when refCount = 0 ). Without investigating too much, it think it will require quite some changes in jackrabbit to account for these changes. The refCount in jackrabbit is used for different purposes then lucene seem to be using it now -Ard > > Why wait to fix an issue that has been identified early on? > > On Jan 29, 2008 11:13 AM, Ard Schrijvers > <[EMAIL PROTECTED]> wrote: > > Hello, > > > > > > > > Hi, > > > > > > I was able to track this issue down in my scenario and > I'll provide > > > a diff later today. In my case I am using Websphere > > > 6.1 and Lucene 2.3.0. It would appear that there is a variable > > > conflict that is only present when utilizing Lucene > 2.3.0, refCount, > > > the reference counter is used in JackRabbit's > > > CachingMultiIndexSearch and in Lucene's IndexReader. > > > > Think you mean CachingMultiIndexReader > > > > > > > > If you make the following changes to CachingMultiIndexSearch the > > > issue appears to be resolved: > > > * Comment out line 64 `private int refCount = 1` > > > * Replace line 159 with `incRef()` > > > * Replace lines 168-170 with `super.doClose()` > > > > > > IndexReader 2.3.0 has the variable refCount and this is > the variable > > > that is checked and results in the thrown exception. > > > CachingMultiIndexSearch has the same variable and increments it > > > accordingly, failing to increment the parent class's variable. > > > > The same variable? It is a private member in > CachingMultiIndexReader. > > Anyway, your solution seems to me like just removing > refCount at all, > > making it very well possible that your indexreader needs to > be opened > > over and over again, or that it is never actually garbage > collected (I > > am guessing because i am not sure about the exact > behavior). I haven't > > tested your solution, but I am quite confident it is not correct. > > > > Also, Jackrabbit 1.4 is released with a dependency on Lucene 2.2.0. > > Perhaps the closing of an IndexReader in lucene has > changed. Anyway, > > can you confirm that you have the same problem with lucene 2.2.0? > > Lucene 2.3.0 will probably be used in the the next jr > version, so if > > it would be a problem, it will certainly be fixed then > > > > -Ard > > > > > > > > > > Hope that helps, > > > Sean > > > > > > > > > > > > On Jan 29, 2008 3:23 AM, Ard Schrijvers > <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > > > > > pls do send the test case (do you have a unit test??) > > > > > > > > Regards Ard > > > > > > > > > > > > > Hi, > > > > > > > > > > I have the same issue. It seems that the only XPATH > query that > > > > > is working is "//*". Anything else will fail with the same > > > exception. I > > > > > can pack a test case (libraries included) and send it. > > > > > > > > > > Julien > > > > > -- > > > > > View this message in context: > > > > > http://www.nabble.com/Lucene-AlreadyClosedException-tp15049132 > > > > > p15152752.html > > > > > Sent from the Jackrabbit - Users mailing list archive at > > > Nabble.com. > > > > > > > > > > > > > > > > > > > >
