FieldCacheImpl concurrency

Hi, I would like to try and improve concurrency in Lucene in several places, and thought I would start with FieldCacheImpl. The implementation is heavily synchronized on both a global map and on creation values for a pretty heavily used path (get). I think the weak hash map is a good solution (

Re: FieldCacheImpl concurrency

On Thu, Feb 11, 2010 at 5:41 PM, Yonik Seeley wrote: > On Thu, Feb 11, 2010 at 9:54 AM, Shay Banon wrote: > >I would like to try and improve concurrency in Lucene in several > places, > > and thought I would start with FieldCacheImpl. The implementation is > heavily >

MoreLikeThis: fieldNames and Query

Hi, I have a few questions regarding more like this: 1. In MoreLikeThis, it seems like the check for fieldNames being null and fetching them from the reader is not done for all the like methods. For example, it does not look like it is done at all for like(Reader r), and on the other hand, it i

Re: 1.9 RC1

Hi, I have just updated to lucene 1.9, and hit a problem with the mentioned optimization. I have applied it to the my JdbcBufferedOutput (I only duplicate the code because the BUFFER_SIZE is final), and I hit a problem. In the following code fragment (the method is writeBytes): ...

Re: 1.9 RC1

Filed the bug, https://issues.apache.org/jira/browse/LUCENE-511 . Also added the simple fix, it seems to work, and I think the rest of the method is ok. Shay On 2 Mar 2006, at 19:19, Doug Cutting wrote: Shay Banon wrote: ... } else { // is data larger then buffer? if

Re: Lucene 1.9.1 release available

And I was hoping to get my name in Lucene CHANGES.txt. You know, something to show my children ;-) On 3 Mar 2006, at 18:26, Doug Cutting wrote: Release 1.9.1 of Lucene is now available from: http://www.apache.org/dyn/closer.cgi/lucene/java/ This fixes a serious bug in 1.9-final. It is stro

Getting an IndexReader from a committed IndexWriter

Hi, I just had a look at the job done in IndexWriter in order to get an IndexReader with all the current ongoing changes done using the IndexWriter. This feature is very useful, and I was wondering if another feature, which (I think) is simple to implement (compared to the previous one) might

Re: Getting an IndexReader from a committed IndexWriter

simply calls IW.getReader > to get new readers containing recent updates. > > -J > > BTW I replied to the message on java-u...@lucene.apache.org. > > On Thu, May 14, 2009 at 6:37 PM, Shay Banon wrote: > >> >> Hi, >> >> I just had a look at the

Re: Getting an IndexReader from a committed IndexWriter

Done: https://issues.apache.org/jira/browse/LUCENE-1637. Jason Rutherglen-2 wrote: > > Ok, that makes sense. Can you open an issue? > > On Thu, May 14, 2009 at 6:56 PM, Shay Banon wrote: > >> >> I was referring in my original post to the code in trunk.

CachingTokenFilter#fillCache problem

Hi, I was going over and playing with Lucene 2.9 and came around something strange that I think might be a bug. In CachingTokenFilter#fillCache it seems like captureState is not called on input and instead is called on CachingTokenFilter. Am I missing something? I got to it since QueryParser u

RE: CachingTokenFilter#fillCache problem

Ohh, now I see. I missed the fact that everybody across the chain share the same attributes. Which explain my bug (I forgot to call super at my tokenizer, thus the attributes were not shared). Thanks! Shay Uwe Schindler wrote: > > Hi Shay, > >>I was going over and playing with Lucene 2.9

Deprecation of flush in IndexWriter

Hi, I was just looking a bit at the trunk. First, let me say that the progress you guys make is amazing!. I would still like to ask a quick question regarding deprecation of flush in IndexWriter. I think that there are cases where flush is needed. For example, in trying to create a two phase (

Re: Deprecation of flush in IndexWriter

t; concurrent merges completes it would also be blocked from committing > the changes to the index until commit(). We should probably also > deprecate abort() and rename it to rollback(). I'll open an issue for > this... > > Mike > > Shay Banon wrote: >> >&

[jira] Created: (LUCENE-2292) ByteBuffer Directory - allowing to store the index outside the heap

Type: New Feature Components: Store Reporter: Shay Banon A byte buffer based directory with the benefit of being able to create direct byte buffer thus storing the index outside the JVM heap. -- This message is automatically generated by JIRA. - You can reply to this email to

[jira] Updated: (LUCENE-2292) ByteBuffer Directory - allowing to store the index outside the heap

[ https://issues.apache.org/jira/browse/LUCENE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shay Banon updated LUCENE-2292: --- Attachment: LUCENE-2292.patch > ByteBuffer Directory - allowing to store the index outside the h

[jira] Commented: (LUCENE-2292) ByteBuffer Directory - allowing to store the index outside the heap

[ https://issues.apache.org/jira/browse/LUCENE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840379#action_12840379 ] Shay Banon commented on LUCENE-2292: Hi, >> looks interesting as a repla

[jira] Updated: (LUCENE-2292) ByteBuffer Directory - allowing to store the index outside the heap

[ https://issues.apache.org/jira/browse/LUCENE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shay Banon updated LUCENE-2292: --- Attachment: LUCENE-2292.patch Attached new patch, does not use sun.* package. I still cache Method

[jira] Commented: (LUCENE-2292) ByteBuffer Directory - allowing to store the index outside the heap

[ https://issues.apache.org/jira/browse/LUCENE-2292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840394#action_12840394 ] Shay Banon commented on LUCENE-2292: By the way, an implementation note. I tho

[jira] Created: (LUCENE-511) New BufferedIndexOutput optimization fails to update bufferStart

: 1.9 Reporter: Shay Banon Priority: Critical Attachments: RAMOutputTest.java New BufferIndexOutput optimization of writeBytes fails to update bufferStart under some conditions. Test case and fix attached. -- This message is automatically generated by JIRA. - If you think it was

[jira] Updated: (LUCENE-511) New BufferedIndexOutput optimization fails to update bufferStart

[ http://issues.apache.org/jira/browse/LUCENE-511?page=all ] Shay Banon updated LUCENE-511: -- Attachment: RAMOutputTest.java > New BufferedIndexOutput optimization fails to update bufferSt

[jira] Updated: (LUCENE-511) New BufferedIndexOutput optimization fails to update bufferStart

[ http://issues.apache.org/jira/browse/LUCENE-511?page=all ] Shay Banon updated LUCENE-511: -- Attachment: BufferedIndexOutput.java > New BufferedIndexOutput optimization fails to update bufferSt

[jira] Commented: (LUCENE-511) New BufferedIndexOutput optimization fails to update bufferStart

[ http://issues.apache.org/jira/browse/LUCENE-511?page=comments#action_12368585 ] Shay Banon commented on LUCENE-511: --- My lucene root is not as clean as it should be. Don't have time to do that, sorry... . Simple copy and paste the BufferedIndexOutp

[jira] Created: (LUCENE-1637) Getting an IndexReader from a committed IndexWriter

Components: Index Affects Versions: 2.9 Reporter: Shay Banon I just had a look at the job done in IndexWriter in order to get an IndexReader with all the current ongoing changes done using the IndexWriter. This feature is very useful, and I was wondering if another feature, which (I

[jira] Created: (LUCENE-1721) IndexWriter to allow deletion by doc ids

Reporter: Shay Banon It would be great if IndexWriter would allow for deletion by doc ids as well. It makes sense for cases where a "query" has been executed beforehand, and later, that query needs to be applied in order to delete the matched documents. More information h

[jira] Commented: (LUCENE-1239) IndexWriter deadlock when using ConcurrentMergeScheduler

[ https://issues.apache.org/jira/browse/LUCENE-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579874#action_12579874 ] Shay Banon commented on LUCENE-1239: Yea, it looks like it is my bad, great c