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
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
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
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
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
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
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
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
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
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).
>
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
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
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
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
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
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
16 matches
Mail list logo