ThreadLocal leak (was Re: Leaking org.apache.lucene.index.* objects)

Moving to java-dev, I think this belongs here. I've been looking at this problem some more today and reading about ThreadLocals. It's easy to misuse them and end up with memory leaks, apparently... and I think we may have this problem here. The problem here is that ThreadLocals are tied to Thre

gdata-server roadmap and open items

Hi All, I'd like to help out with gdata-server, and was wondering if there is a list of roadmap or open items. Can Simon or someone familiar with the project point me in the right direction? Thanks, Garth - To unsubscribe, e-mail

Re: potential indexing perormance improvement for compound index - cut IO - have more files though

I think Doron is right on the money here. I know one "customer" who'd be happy to trade its file descriptors for less IO - simpy.com. It's exactly what Doron describes - a busy system with a LOT of indices. File descriptors are kept under control by carefully closing IndexSearchers, plus I ca

Re: potential indexing perormance improvement for compound index - cut IO - have more files though

"Mike Klaas" <[EMAIL PROTECTED]> wrote: > > My main comment is that the benefits of this change can be achieved by > using the non-compound index format. For people that care about the > difference in performance, it isn't difficult to configure your system > to mitigate the problems of the non-co

[jira] Created: (LUCENE-751) cannot retrieve term positions from indices using ISOLatin1AccentFilter

cannot retrieve term positions from indices using ISOLatin1AccentFilter --- Key: LUCENE-751 URL: http://issues.apache.org/jira/browse/LUCENE-751 Project: Lucene - Java Issue

[jira] Updated: (LUCENE-749) ChainedFilter does not work well in the event of filters in ANDNOT

[ http://issues.apache.org/jira/browse/LUCENE-749?page=all ] Antonio Bruno updated LUCENE-749: - Attachment: ChainedFilter.patch.txt In this way it is avoided that the first ANDNOT operation takes place against a completely false bitset and will always r

Re: Lucene code review

Brian Chess wrote: I'd be happy to set up an account for anyone involved with the projects who'd like to take a look. (Because we're checking for security problems, we don't share specific findings with the general public.) Thanks for doing this, Brian. One possibility would be to generate Ji

Re: potential indexing perormance improvement for compound index - cut IO - have more files though

On 12/14/06, Doron Cohen <[EMAIL PROTECTED]> wrote: But anyhow, this is not a negligible difference, and for real large indexes, and busy systems, when the just written non-compound segment is not in the system caches, it might have more effect. Possibly, search performance during indexing would

Re: 15 minute hang in IndexInput.clone() involving finalizers

Yonik and Robert, thanks for the suggestions and pointer to the patch! We've looked at the synchronization involved with finalizers and don't see how it could cause the issue as running the finalizers themselves is outside the lock. The code inside the lock is simple fixed-time list manipulation,

Re: 15 minute hang in IndexInput.clone() involving finalizers

I don't think there is necessarily a limit, but I am assuming there is some interaction between the finalizer or GC threads and adding new finalizers, which would require some sort of synchronization. Do you use network resources in your app? I have a hunch this is somehow the cause. On

Re: 15 minute hang in IndexInput.clone() involving finalizers

On 12/15/06, robert engels <[EMAIL PROTECTED]> wrote: If you could post a complete thread dump that would be better. I am "thinking" that it is not really a bug, but that the finalizer or GC thread is very busy, or possibly blocked on a network resource, and that is preventing the addition of ad

Re: 15 minute hang in IndexInput.clone() involving finalizers

If you could post a complete thread dump that would be better. I am "thinking" that it is not really a bug, but that the finalizer or GC thread is very busy, or possibly blocked on a network resource, and that is preventing the addition of additional finalizers. (sorry for the double post b

Re: [jira] Created: (LUCENE-750) don't use finalizers for FSIndexInput clones

If you could post a complete thread dump that would be better. I am "thinking" that it is not really a bug, but that the finalizer or GC thread is very busy, or possibly blocked on a network resource, and that is preventing the addition of additional finalizers. On Dec 15, 2006, at 10:12 A

[jira] Commented: (LUCENE-749) ChainedFilter does not work well in the event of filters in ANDNOT

[ http://issues.apache.org/jira/browse/LUCENE-749?page=comments#action_12458839 ] Antonio Bruno commented on LUCENE-749: -- I correct myself. Task that would have in this way to be: if (logic == AND) { result = (Bi

[jira] Commented: (LUCENE-749) ChainedFilter does not work well in the event of filters in ANDNOT

[ http://issues.apache.org/jira/browse/LUCENE-749?page=comments#action_12458838 ] Yonik Seeley commented on LUCENE-749: - Thanks Antonio, Could you attach a patch (and click "Grant license to ASF for inclusion in ASF works") If you can, a tes

Re: 15 minute hang in IndexInput.clone() involving finalizers

That is odd, Chuck... looks like a JVM bug to me. What do you think of the following patch? http://issues.apache.org/jira/browse/LUCENE-750 -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server On 12/15/06, Chuck Williams <[EMAIL PROTECTED]> wrote: Hi All, I've ha

[jira] Updated: (LUCENE-750) don't use finalizers for FSIndexInput clones

[ http://issues.apache.org/jira/browse/LUCENE-750?page=all ] Yonik Seeley updated LUCENE-750: Attachment: IndexInput_finalizer.patch Changes: - moved finalizer to the resource that actually needs it... the Descriptor (subclass of RandomAccessFile). Th

[jira] Created: (LUCENE-750) don't use finalizers for FSIndexInput clones

don't use finalizers for FSIndexInput clones Key: LUCENE-750 URL: http://issues.apache.org/jira/browse/LUCENE-750 Project: Lucene - Java Issue Type: Improvement Components: Search Af

[jira] Commented: (LUCENE-749) ChainedFilter does not work well in the event of filters in ANDNOT

[ http://issues.apache.org/jira/browse/LUCENE-749?page=comments#action_12458830 ] Antonio Bruno commented on LUCENE-749: -- It would have in this way to be: ... - if (logic == AND) + if (logic == AND || logic == ANDNOT)

[jira] Created: (LUCENE-749) ChainedFilter does not work well in the event of filters in ANDNOT

ChainedFilter does not work well in the event of filters in ANDNOT --- Key: LUCENE-749 URL: http://issues.apache.org/jira/browse/LUCENE-749 Project: Lucene - Java Issue Type: I

Re: Lucene code review

Erik Hatcher wrote: > I have an account and I recommend at least a couple of the really active > committers sign on as well. Yonik for sure! ;) Doug, of course (if he > wants). Anyone else? I am interested check out Nutch. -- Sami Siren --

Re: Lucene code review

I have an account and I recommend at least a couple of the really active committers sign on as well. Yonik for sure! ;) Doug, of course (if he wants). Anyone else? Erik On Dec 15, 2006, at 1:42 AM, Brian Chess wrote: Hi Erik, thanks for the intro. I'd be happy to set up an ac

Re: Lucene code review

Hi Erik, thanks for the intro. I'd be happy to set up an account for anyone involved with the projects who'd like to take a look. (Because we're checking for security problems, we don't share specific findings with the general public.) Erik is right, from Lucene, Nutch, and Solr, the most import

potential indexing perormance improvement for compound index - cut IO - have more files though

Hi, I would like to propose and get feedback on a potential indexing performance improvement for the case that compound file is used (this is the default). In compound segment mode, each merge operation is ended by writing a compound file. To be more precise, the merge result is first written to

15 minute hang in IndexInput.clone() involving finalizers

Hi All, I've had a bizarre anomaly arise in an application and am wondering if anybody has ever seen anything like this. Certain queries, in not easy to reproduce cases, take 15-20 minutes to execute rather than a few seconds. The same query is fast some times and anomalously slow others. This

Re: GData & DB4o reloaded

Yes legal-discuss might be the best way to get a concrete answer. I will discuss that as soon as I got back from the US. best regards simon On 12/13/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: Probably best to go to legal-discuss. I think the "non-transferable" restriction in section 2

Fwd: Lucene code review

(sorry if this is a duplicate post, wanted to be sure it made it through) Erik Begin forwarded message: From: Brian Chess <[EMAIL PROTECTED]> Date: December 15, 2006 1:42:13 AM EST To: Erik Hatcher <[EMAIL PROTECTED]>, [EMAIL PROTECTED]> Cc: Gary McGraw <[EMAIL PROTECTED]> Subject: