I apologize, I did in fact mean CachingMultiIndexReader. CachingMultiIndexReader is a child class of IndexReader and therefore I use the refCount that can be found in IndexReader. It is this variable that is being checked in the "ensureOpen" function which is responsible for this exception being thrown. If you step through the flow you'll notice that the value is never incremented in IndexReader but rather the second refCount created in CachingMultiIndexReader is incremented. So yes, my solution does result in the removal of refCount being created as a private variable in the child of IndexReader. There seems to be no reason for these duplicates and with them Lucene 2.3.0 does not seem to function.
I have not tried 2.2.0 and will continue to utilize 2.3.0 as it is the latest version of Lucene and seems to function properly with this change. For testing purposes I will try and look through 2.2.0 to see if there is still a conflict with the refCount variable. 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. > > > > > > > > > > > > > >
