> I have not tried 2.2.0 and will continue to utilize 2.3.0 as Ofcourse you are totally free to do so, but I guess you can update lots of dependencies on jars which might have newer releases. I just don't understand why you are convinced that everything works with 2.3.0. Ideally, it would, but there is a reason why a pom.xml contains a version to some used jar.
> 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? Again, I saw how you tried to fix the issue, and it simply isn't a fix. As far as I can see you just removed the refCount. So, when a index reader in your case gets closed, it is closed instantly, while another request might still be using it (multithreaded environment, hence ref counting, etc etc). Anyway, I now explained it twice, your fix is not a fix, and the current released version of jr 1.4 which depends on lucene 2.2.0 does not have this problem. If we start to use lucene 2.3.0 we will fix this problem properly, -Ard > > 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. > > > > > > > > > > > > > > > > > > > >
