Hi, We have been using Lucene 3.1 version with Tomcat 4.0 and jdk1.4. It seems that sometimes we see a "Too many files open" exception which completely garbles the whole index and whole search functionality crashes on the web site. It has also been known to crash the complete JSP container of tomcat.
After looking at the bug list, we found out that it has been reported as a bug in the Lucene bug list as Bug#29774, #30049, #30452 which claims to have been resolved with the new version of Lucene. We have tried everything to reproduce the problem ourselves to figure out the exact circumstances under which it occurs but with out any luck. We would be installing the new version of Lucene but we need to be able to reproduce the problem to test it. We would really appreciate it if someone could point us to the root cause behind this so we can devise a solution around that. Thanks and regards Neelam Bhatnagar Technology| Sapient Presidency Building Mehrauli-Gurgaon Road Sector-14, Gurgaon-122001 Haryana, India Tel: 91.124.2826299 Cell: 91.9899591054 Email: [EMAIL PROTECTED] -----Original Message----- From: Tatu Saloranta [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 17, 2004 6:37 AM To: Lucene Developers List Subject: Re: jdk 1.3 versus jdk 1.4 On Tuesday 16 November 2004 13:15, Bernhard Messer wrote: > >On Monday 15 November 2004 13:47, Bernhard Messer wrote: > >>Hi, ... > >The reason this is sometimes useful is that knowledge about nested > > exception is very useful for debugging; especially line numbers. > > (in my case I use it to keep Woodstox XML-parser 1.2 compatible, while > > using LinkedHashMap, and nested exceptions, if possible) > > > >The solution is not a one-liner though (if someone is interested, let me > > know and I can point you to the source code), so maybe it's easier to > > just "dumb it down" to using String constructor. But I just thought I'll > > mention that it can be completely resolved if it seems worthwhile. :-) > > you're right, i like the idea creating a nested exception. For the > particular case, it would be enough to create a NestedRuntimeException > which works under both JVM's. Or, the alternate way; 1.4 has Throwable.initCause(), so that you can do: ... } catch (IOException ie) { Throwable t = new RuntimeException("Problems!!!"); t.initCause(ie); throw t; } instead of } catch (IOException ie) { throw new RuntimeException("Problems", ie); } And because of this, you can create a simple utility method that (a) Takes two Throwables as arguments (new exception to throw, the nested exception) (b) Uses reflection to find method Throwable.initCause(); catching NoSuchMethodException for 1.3 (c) If (b) returns (non-null), call Method on the first Throwable, passing second one as argument. This utility method can actually be called either from code that constructs the exception; or in case of a derived exception, from its constructor. Above may sound more complicated than it really is.... it's less than 10 lines of code, all in all. Anyway, I don't have a strong preference either way, but if someone feels it worth pursuing, feel free to implement the idea :-) -+ Tatu +- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
