Re: IndexWriter.close() no longer seems to close everything

2009-11-13 Thread Albert Juhe
I don't know how, because the problem is with JBOSS in a productions environment, in a localhost this don't happens. The JBOSS server is in a production environment, contains a lot of projects, I don't know if Lucene enters in fight with othe libraries. I don't have control of this computer, I

Re: IndexWriter.close() no longer seems to close everything

2009-11-13 Thread Michael McCandless
Alas, I can't repro this problem ("leaking file descriptors with NRT"), either. I've got a decent stress test setup -- start with a 5M Wikipedia index, update (delete & add) @ 1000 docs/sec (using 2 threads), reopen 10X per second, searching at redline (using 9 threads), and the open file descript

Re: IndexWriter.close() no longer seems to close everything

2009-11-13 Thread Michael McCandless
Any luck narrowing this to a standalone test case that shows the problem? That new exception appears to be inside the Java code created by the app server compiling your JSP -- it's not very helpful since it doesn't "enter" Lucene. Can you try to narrow this to a standalone test case, too? Thanks

Re: IndexWriter.close() no longer seems to close everything

2009-11-13 Thread Albert Juhe
Hi, About this problem I did a test yesterday, I did a downgrade, I changed versión 2.9.1 to 2.4.1, and the problem has been solved, all the files are closed corretly and JBOSS isn't unstable. Another problem that we have observed is: Sometimes, random success, when you try to make a serach the

Re: IndexWriter.close() no longer seems to close everything

2009-11-12 Thread Jason Rutherglen
If there's a bug you're seeing, it's helpful to open an issue and post code reproducing it. On Wed, Nov 11, 2009 at 3:41 AM, Albert Juhe wrote: > > I think that this is the best way to proceed. > > thank you Mike > > > > Michael McCandless-2 wrote: >> >> Can you narrow the leak down to a small se

Re: IndexWriter.close() no longer seems to close everything

2009-11-12 Thread John Wang
If you run the zoie test turned to nrt, you can replicate it rather easily: While the test is running, do lsof on your process, e.g. lsof -p | | wc -John On Thu, Nov 12, 2009 at 8:24 AM, John Wang wrote: > Well, I have code in the finally block to call IndexReader.close for every > reader I

Re: IndexWriter.close() no longer seems to close everything

2009-11-12 Thread John Wang
Well, I have code in the finally block to call IndexReader.close for every reader I get from IndexWriter.getReader. On Mon, Nov 9, 2009 at 2:43 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > Does this look like a real leak John? You're definitely closing every > reader you get back

Re: IndexWriter.close() no longer seems to close everything

2009-11-11 Thread Albert Juhe
I think that this is the best way to proceed. thank you Mike Michael McCandless-2 wrote: > > Can you narrow the leak down to a small self-contained test? > > Mike > > On Wed, Nov 11, 2009 at 5:54 AM, Albert Juhe wrote: >> >> I don't get any exception. >> >> thank you Mike >> >> >> Michael

Re: IndexWriter.close() no longer seems to close everything

2009-11-11 Thread Michael McCandless
Can you narrow the leak down to a small self-contained test? Mike On Wed, Nov 11, 2009 at 5:54 AM, Albert Juhe wrote: > > I don't get any exception. > > thank you Mike > > > Michael McCandless-2 wrote: >> >> Do you see your exception handler printing anything out? >> >> You don't need to close t

Re: IndexWriter.close() no longer seems to close everything

2009-11-11 Thread Albert Juhe
I don't get any exception. thank you Mike Michael McCandless-2 wrote: > > Do you see your exception handler printing anything out? > > You don't need to close the underlying IndexReader, just the > IndexSearcher (which will close the IndexReader, since it was the one > that had opened it). >

Re: IndexWriter.close() no longer seems to close everything

2009-11-11 Thread Michael McCandless
Do you see your exception handler printing anything out? You don't need to close the underlying IndexReader, just the IndexSearcher (which will close the IndexReader, since it was the one that had opened it). Mike On Wed, Nov 11, 2009 at 5:10 AM, Albert Juhe wrote: > > I don't know if it's the

Re: IndexWriter.close() no longer seems to close everything

2009-11-11 Thread Albert Juhe
I don't know if it's the same problem but I think it's similar, My problem is with the Indexsearcher. I've installed a web search engine that uses Lucene, after a search I make a close operation like this: private IndexSearcher searcher; NIOFSDirectory directory = new NIOFSDirectory(new File(p

Re: IndexWriter.close() no longer seems to close everything

2009-11-09 Thread Michael McCandless
Does this look like a real leak John? You're definitely closing every reader you get back from getReader? Mike On Sun, Nov 8, 2009 at 10:41 PM, John Wang wrote: > I am seeing the samething, but only when IndexWriter.getReader is called at > a high rate. > > from lsof, I see file handles growing

Re: IndexWriter.close() no longer seems to close everything

2009-11-08 Thread Daniel Noll
On Mon, Nov 9, 2009 at 14:41, John Wang wrote: > I am seeing the samething, but only when IndexWriter.getReader is called at > a high rate. > > from lsof, I see file handles growing. This hint turned out to help. :-) Turns out we had an IndexReader hanging around from a previous index state (bef

Re: IndexWriter.close() no longer seems to close everything

2009-11-08 Thread John Wang
I am seeing the samething, but only when IndexWriter.getReader is called at a high rate. from lsof, I see file handles growing. -John On Sun, Nov 8, 2009 at 7:29 PM, Daniel Noll wrote: > Hi all. > > We updated to Lucene 2.9, and now we find that after closing our text > index, it is not possib

IndexWriter.close() no longer seems to close everything

2009-11-08 Thread Daniel Noll
Hi all. We updated to Lucene 2.9, and now we find that after closing our text index, it is not possible to rename the directory in which it resides (we are actually renaming a directory further up the hierarchy.) We discovered that the following files were still open by the process: _0.tis, _0