lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neelam Bhatnagar" <>
Subject Too many files open bug
Date Wed, 17 Nov 2004 13:29:30 GMT


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

-----Original Message-----
From: Tatu Saloranta [] 
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,
> > using LinkedHashMap, and nested exceptions, if possible)
> >
> >The solution is not a one-liner though (if someone is interested, let
> > know and I can point you to the source code), so maybe it's easier
> > just "dumb it down" to using String constructor. But I just thought
> > 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

} catch (IOException ie) {
  Throwable t = new RuntimeException("Problems!!!");
  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,
  second one as argument.

This utility method can actually be called either from code that
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
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:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message