[
http://issues.apache.org/jira/browse/LUCENE-754?page=comments#action_12459831 ]
Oliver Hutchison commented on LUCENE-754:
-
Chuck and whoever else got burned by this - really big apology for letting that
typo slip into my patch :-( Unfo
[ http://issues.apache.org/jira/browse/LUCENE-753?page=all ]
Yonik Seeley updated LUCENE-753:
Attachment: FSIndexInput.patch
Here is a patch that directly extends IndexInput to make things a little easier.
I started with the code for BufferedIndexInput t
Hi Otis,
Lucene has been an integral part of Parabuild server. Viewtier Systems
decided to give back by hosting continuous integration for Lucene that
is run by Parabuild.
Now Parabuild will re-build Lucene whenever new changes are committed
to the repository and send a message to the dev lis
[
http://issues.apache.org/jira/browse/LUCENE-651?page=comments#action_12459816 ]
Otis Gospodnetic commented on LUCENE-651:
-
For the record, this patch had a small mistake in it, causing memory leakage.
The fix is in LUCENE-754.
> Poo
[ http://issues.apache.org/jira/browse/LUCENE-754?page=all ]
Yonik Seeley resolved LUCENE-754.
-
Resolution: Fixed
patch committed.
> FieldCache keeps hard references to readers, doesn't prevent multiple threads
> from creating same instance
> -
[ http://issues.apache.org/jira/browse/LUCENE-436?page=all ]
Otis Gospodnetic updated LUCENE-436:
Attachment: LUCENE-436.patch
This patch removes finalize() in TermInfosReader and SegmentReader, and it adds
the enumerators.remove() call in TermInfos
[
http://issues.apache.org/jira/browse/LUCENE-436?page=comments#action_12459813 ]
Yonik Seeley commented on LUCENE-436:
-
The more finalizers we can get rid of, the better. They are too hard to use
correctly and cause performance problems.
h
On 12/19/06, robert engels <[EMAIL PROTECTED]> wrote:
That is what I did in my implementation.
It is easy to implement this as a protected abstract method in
IndexInput, which uses synchronization (and seek(), read(byte
[],off,len). In the 'real" version just override it to do it properly
withou
That is what I did in my implementation.
It is easy to implement this as a protected abstract method in
IndexInput, which uses synchronization (and seek(), read(byte
[],off,len). In the 'real" version just override it to do it properly
without using seek().
On Dec 19, 2006, at 7:40 PM,
[
http://issues.apache.org/jira/browse/LUCENE-753?page=comments#action_12459805 ]
Yonik Seeley commented on LUCENE-753:
-
CSIndexInput synchronization could also be elimitated if there was a pread
added to IndexInput
public abstract void r
Some work on NIO-based FSDirectory has already been done. Some performance
info is included, too:
http://issues.apache.org/jira/browse/LUCENE-519
http://issues.apache.org/jira/browse/LUCENE-414
Otis
- Original Message
From: Doug Cutting <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.o
Hello,
Given a prefix query such as "Jame*" and an index containing the
following entries:
Someone that is named James
James Brown
James Crown
John James Mathew
Jameson Jones
Mathew Jamesville
Dewitt Hank James
I'd like Lucene to return the results in the following order:
James Brown
James Crow
[
http://issues.apache.org/jira/browse/LUCENE-754?page=comments#action_12459791 ]
Chuck Williams commented on LUCENE-754:
---
This patch, together with LUCENE-750 (already committed) solved our problem
completely. It sped up simultaneous mul
: > What do you think about that alternative approach I mentioned? Instead of
having FieldCacheImpl be aware of all IndexReaders, have FieldCache be an inst
var in IndexReader?
:
: I wonder why it wasn't done that way to start with perhaps to
: completely separate sorting from index reading
I think Robert might have still had LUCENE-436 in the back of his mind.
I think I'll take care of that one soon - I think those finalize() overrides
are no longer missing, and that's the only "issue" in LUCENE-436. I think
finalize()s there are not hurting us, but since they contain hacks for
p
[ http://issues.apache.org/jira/browse/LUCENE-436?page=all ]
Otis Gospodnetic reassigned LUCENE-436:
---
Assignee: Otis Gospodnetic
> [PATCH] TermInfosReader, SegmentTermEnum Out Of Memory Exception
> --
[
http://issues.apache.org/jira/browse/LUCENE-436?page=comments#action_12459779 ]
Otis Gospodnetic commented on LUCENE-436:
-
My leak ended up being caused by the patch in LUCENE-651 and is fixed by
LUCENE-754.
The only thing left to do
Doron Cohen wrote:
Something in how Deleter is called by IndexReader.commit that I don't
understand: IndexReader.commit() starts with:
if(hasChanges){
if (deleter == null) {
// In the MultiReader case, we share this deleter
// across all SegmentReaders:
setDelete
Sorry, it wasn't this particular thread. Sorry for the confusion.
This thread is actually on the money I believe (The FieldCache issues).
I got my wires crossed during a vent. It is just difficult when you
spend numerous hours to diagnose "the problem" and then have to
revisit the same issu
[ http://issues.apache.org/jira/browse/LUCENE-750?page=all ]
Yonik Seeley resolved LUCENE-750.
-
Resolution: Fixed
committed.
> don't use finalizers for FSIndexInput clones
>
>
> Key: LUCENE-75
On 12/19/06, robert engels <[EMAIL PROTECTED]> wrote:
I would suggest that in order to even bring up "thread local issues"
in the future that the submitter supplies a pure Java NON-LUCENE test
case that demonstrates the problem (just as you would if reporting a
bug to Sun).
All of the "guessing"
[
http://issues.apache.org/jira/browse/LUCENE-754?page=comments#action_12459763 ]
Chuck Williams commented on LUCENE-754:
---
Cool! This should solve at least part of my problem. Trying this now (along
with finalizer removal patch that is a
Something in how Deleter is called by IndexReader.commit that I don't
understand: IndexReader.commit() starts with:
if(hasChanges){
if (deleter == null) {
// In the MultiReader case, we share this deleter
// across all SegmentReaders:
setDeleter(new IndexFileDelet
I would suggest that in order to even bring up "thread local issues"
in the future that the submitter supplies a pure Java NON-LUCENE test
case that demonstrates the problem (just as you would if reporting a
bug to Sun).
All of the "guessing" about what is going on is counter productive.
On 12/19/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
Bingo! :) I'll try the patch shortly and report back in a bit.
Cool, since you can serve as a test-case, I'll hold of on committing
until I hear how it works.
What do you think about that alternative approach I mentioned? Instead of
Brian Chess wrote:
My question is, would you like to allow outsiders to go through results and
help sort the real bugs from the chaff?
That's up to you. It's your service, not governed by the Apache Lucene
project. If you cause your system to add reasonable issues to our
bug-tracking system
: application vulnerable or is really just a "ruckus" issue? Part of
: me thinks that b/c the code is freely available, people could find
: the security issues anyway, so we aren't really protecting ourselves
: anyway by denying access.
Personally I agree ... if the source is free, all exposing
Bingo! :) I'll try the patch shortly and report back in a bit.
What do you think about that alternative approach I mentioned? Instead of
having FieldCacheImpl be aware of all IndexReaders, have FieldCache be an inst
var in IndexReader? That way we can clean up/lose reference to FieldCache whe
LOL! of course I stopped to open the bug,
grab a sandwitch, etc ;-)
On 12/19/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
Ha! ... I beat you by 16 whole seconds!
You have to be faster then that if you want to roll with the Big Dogs!
: Date: Tue, 19 Dec 2006 11:50:07 -0800 (PST)
: From: Chris
Ha! ... I beat you by 16 whole seconds!
You have to be faster then that if you want to roll with the Big Dogs!
: Date: Tue, 19 Dec 2006 11:50:07 -0800 (PST)
: From: Chris Hostetter
: Subject: Re: ThreadLocal leak (was Re: Leaking org.apache.lucene.index.*
: Date: Tue, 19 Dec 2006 11:50:23 -080
On Dec 19, 2006, at 12:16 AM, Brian Chess wrote:
My question is, would you like to allow outsiders to go through
results and
help sort the real bugs from the chaff? The upside is that
volunteers may
perform useful work and that it may be another avenue to get people
involved
with the co
[ http://issues.apache.org/jira/browse/LUCENE-754?page=all ]
Yonik Seeley updated LUCENE-754:
Attachment: FieldCache.patch
typo in original (used reader instead of key)
> FieldCache keeps hard references to readers, doesn't prevent multiple threads
> f
On 12/19/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 12/19/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
> What I'm seeing while profiling (and in production) is the accumulation of
these:
>
> org.apache.lucene.search.FieldCacheImpl$Entry
> org.apache.lucene.search.FieldCacheImpl$CreationPl
FieldCache keeps hard references to readers, doesn't prevent multiple threads
from creating same instance
-
Key: LUCENE-754
URL: http://issues.apache.org/jira/
: Can anyone else have a look at the patch for LUCENE-651 (or just at
: FieldCacheImpl) and see if there is a quick fix?
If i'm not mistaken, isn't line #65 wrong? ...
synchronized (readerCache) {
innerCache = (Map) readerCache.get(reader);
if (innerCache == null) {
On 12/19/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
I _think_ Robert is right and ThreadLocals are not the problem (I tried getting
rid of them, and replacing them with an instance var last week, but run into
problems with multi-threaded unit tests).
If you want to try getting rid of the
Hi,
I _think_ Robert is right and ThreadLocals are not the problem (I tried getting
rid of them, and replacing them with an instance var last week, but run into
problems with multi-threaded unit tests).
What I'm seeing while profiling (and in production) is the accumulation of
these:
org.apach
[
http://issues.apache.org/jira/browse/LUCENE-753?page=comments#action_12459731 ]
Doug Cutting commented on LUCENE-753:
-
This patch continues to use BufferedIndexInput and allocates a new ByteBuffer
for each call to read(). I wonder if it m
[
http://issues.apache.org/jira/browse/LUCENE-753?page=comments#action_12459724 ]
Yonik Seeley commented on LUCENE-753:
-
This change should be faster on heavily loaded multi-threaded servers using the
non-compound index format.
Performance t
[ http://issues.apache.org/jira/browse/LUCENE-753?page=all ]
Yonik Seeley updated LUCENE-753:
Attachment: FSIndexInput.patch
Patch for FSIndexInput to use a positional read call that doesn't use explicit
synchronization. Note that the implementation of
Use NIO positional read to avoid synchronization in FSIndexInput
Key: LUCENE-753
URL: http://issues.apache.org/jira/browse/LUCENE-753
Project: Lucene - Java
Issue Type: New Fea
Doug Cutting wrote:
[EMAIL PROTECTED] wrote:
LUCENE-748: add javadoc around semantics of Exception during
IndexWriter.close()
LUCENE-129: fix finalizers to always call super.finalize
LUCENE-301: add new constructors IndexWriter({String,File,Directory},
Analyzer) that create index if it's not a
[EMAIL PROTECTED] wrote:
LUCENE-748: add javadoc around semantics of Exception during IndexWriter.close()
LUCENE-129: fix finalizers to always call super.finalize
LUCENE-301: add new constructors IndexWriter({String,File,Directory}, Analyzer)
that create index if it's not already there, else app
[
http://issues.apache.org/jira/browse/LUCENE-750?page=comments#action_12459667 ]
Michael McCandless commented on LUCENE-750:
---
For FSIndexOutput ... assuming we are quite certain that nowhere in
Lucene do we fail to close an IndexOutpu
Yonik Seeley wrote:
On 12/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
LUCENE-129: fix finalizers to always call super.finalize
Michael, do you have any opinion on if the finalizer on FSIndexOutput
should be kept?
LUCENE-750 removes it...
OK I just added comment in LUCENE-750 (short a
On 12/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
LUCENE-129: fix finalizers to always call super.finalize
Michael, do you have any opinion on if the finalizer on FSIndexOutput
should be kept?
LUCENE-750 removes it...
-Yonik
[ http://issues.apache.org/jira/browse/LUCENE-301?page=all ]
Michael McCandless resolved LUCENE-301.
---
Fix Version/s: 2.1
Resolution: Fixed
OK I've added the new constructors for IndexWriter. Thank you Dan and sorry
for the long delay!
> I
[ http://issues.apache.org/jira/browse/LUCENE-129?page=all ]
Michael McCandless resolved LUCENE-129.
---
Fix Version/s: 2.1
Resolution: Fixed
OK I've fixed all cases of finalize except for one under contrib
(contrib/memory/src/java/org/apache/
[ http://issues.apache.org/jira/browse/LUCENE-748?page=all ]
Michael McCandless resolved LUCENE-748.
---
Fix Version/s: 2.1
Resolution: Fixed
OK I just commited the fix to the javadoc. Thanks Jed!
> Exception during IndexWriter.close() preven
It can with lucene joining two indices and form a single query?
That is, a document must have some fields indexes to you on the first index and
other fields index to you on second to index.
If this possibility as exists it could be made?
Thanks.
Antonio Bruno
50 matches
Mail list logo
