It occures to me that IndexInput.clone() probably isn't mt-safe.
If you call clone() on an IndexInput that is being used by another
thread, you can presumably get a new IndexInput that's in an invalid
state. BufferedIndexInput would seem susceptible.
Are lazy fields unsafe because they clone a p
[ http://issues.apache.org/jira/browse/LUCENE-678?page=all ]
Michael McCandless reopened LUCENE-678:
---
Assignee: Michael McCandless (was: Yonik Seeley)
> [PATCH] LockFactory implementation based on OS native locks (java.nio.*)
> ---
[
http://issues.apache.org/jira/browse/LUCENE-678?page=comments#action_12443394 ]
Michael McCandless commented on LUCENE-678:
---
OK! Sorry, you are correct. Of course on closing the first
IndexWriter cleanly, it will remove its lock fil
NullPointerException thrown by equals method in SpanOrQuery
---
Key: LUCENE-689
URL: http://issues.apache.org/jira/browse/LUCENE-689
Project: Lucene - Java
Issue Type: Bug
Com
[ http://issues.apache.org/jira/browse/LUCENE-489?page=all ]
Steven Parkes updated LUCENE-489:
-
Lucene Fields: [Patch Available]
Fix Version/s: 2.1
Assignee: Steven Parkes
> Allow QP subclasses to support Wildcard Queries with leading "*"
>
[ http://issues.apache.org/jira/browse/LUCENE-667?page=all ]
Steven Parkes updated LUCENE-667:
-
Lucene Fields: [Patch Available]
Fix Version/s: 2.1
Assignee: Steven Parkes
> javacc skeleton files not regenerated
> ---
[ http://issues.apache.org/jira/browse/LUCENE-661?page=all ]
Steven Parkes updated LUCENE-661:
-
Lucene Fields: [Patch Available]
Fix Version/s: 2.1
Assignee: Steven Parkes
> BUILD.txt instructions wrong for JavaCC
> -
The bottom line is:
> 1) TermDocs has a close method
> 2) anything implimenting TermDocs should be able to trust
that
> close() will be called
> 3) anything iterating over a TermDocs should call close()
>
> ...ergo: TermScorer needs a c
Currently IndexWriter.flushRamSegments() always merge all ram segments to
disk. Later it may merge more, depending on the maybe-merge algorithm. This
happens at closing the index and when the number of (1 doc) (ram) segments
exceeds max-buffered-docs.
Can there be a performance penalty for always
[ http://issues.apache.org/jira/browse/LUCENE-688?page=all ]
Steven Parkes closed LUCENE-688.
Lucene Fields: (was: [New])
Resolution: Invalid
Whoops .. didn't take the time to see that the FAQ link on the web site points
to the wiki.
> Add a F
BTW, I added new fields to Lucene for "New" issues and "Patch
Available".
Cool. Shows up on the create and edit pages which seem to be the most
important.
It won't show up when creating a filter unless the filter already has
"Lucene Java" specified in the first entry because it's
: BTW, I added new fields to Lucene for "New" issues and "Patch
: Available". This is much lighter-weight than switching the workflow,
: although it doesn't seem to appear on all the screens yet. Perhaps it
: just takes a while...
Ah-HA! ... very cool.
FYI: if you click the "Configure your Iss
Any idea when you're going to post a snapshot of your 675 stuff, Grant?
-Original Message-
From: Grant Ingersoll [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 18, 2006 1:18 PM
To: java-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENE-687) Performance improvement:
Lazy ski
Can you share your performance test as well as the results?
http://issues.apache.org/jira/browse/LUCENE-675
Thanks,
Grant
On Oct 18, 2006, at 3:41 PM, Michael Busch (JIRA) wrote:
[ http://issues.apache.org/jira/browse/LUCENE-687?
page=comments#action_12443343 ]
Michael Busch commented o
I need to reread the FAQ a few times to remember what's in it. But I'll
do some light rewording to make it less 1.4/1.5 specific.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Add a FAQ entry explaning release naming.
-
Key: LUCENE-688
URL: http://issues.apache.org/jira/browse/LUCENE-688
Project: Lucene - Java
Issue Type: Improvement
Components: Website
: That's the convention we've used in Lucene projects. The idea is that
: users should have to go out of their way to build something named
: lucene-2.0.0.jar, since they're likely to patch things. Only the
: official builds should look like official builds, everything else should
: look like a
Doug Cutting <[EMAIL PROTECTED]> wrote on 18/10/2006 13:03:28:
> Yes, this confuses a lot of folks and probably deserves an FAQ.
To some extent, it is already in the FAQ -
http://wiki.apache.org/jakarta-lucene/LuceneFAQ#head-42361d89c6ea75536ba2780543c60e1fd9c9b682
-
Steven Parkes (JIRA) wrote:
Hmmm ... I've been wondering about this. Turns out that both the svn tag lucene_2_0_0 and
the 2.0.0 src tar ball have "2.0.1-dev" in common-build.xml. I don't know if
this was intentional, so that the someone using the signed binary tar ball would be
clearly disting
Yonik Seeley wrote:
On 10/18/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
A quick glance at recent Jira activity suggests that
the following folks might be added to the lucene-developers group:
Doron Cohen
Karl Wettin
Michael McCandless
Michael Busch
Ning Li
+1 to these
Done.
[
http://issues.apache.org/jira/browse/LUCENE-679?page=comments#action_12443344 ]
Steven Parkes commented on LUCENE-679:
--
Hmmm ... I've been wondering about this. Turns out that both the svn tag
lucene_2_0_0 and the 2.0.0 src tar ball have
[
http://issues.apache.org/jira/browse/LUCENE-687?page=comments#action_12443343 ]
Michael Busch commented on LUCENE-687:
--
Hi Yonik,
thanks for the quick reply! I'm going to do performance tests and will give you
some numbers soon.
> Perfo
On 10/18/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
A quick glance at recent Jira activity suggests that
the following folks might be added to the lucene-developers group:
Doron Cohen
Karl Wettin
Michael McCandless
Michael Busch
Ning Li
+1 to these
Abdul Chaudhry
He open
Doug Cutting wrote:
Steven Parkes wrote:
I would like to be added to the Jira developer list.
I'm also happy to add other contributors, so that they can assign
themselves issues. A quick glance at recent Jira activity suggests that
the following folks might be added to the lucene-developers
Steven Parkes wrote:
I would like to be added to the Jira developer list.
Done.
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[
http://issues.apache.org/jira/browse/LUCENE-678?page=comments#action_1244 ]
Doron Cohen commented on LUCENE-678:
Michael, I must be misunderstanding something then...
> That test case is verifying that the 2nd index writer indeed remov
Steven Parkes wrote:
Just because you've gotten back doesn't mean the issue is gone.
No, just clarifying whose court the ball is in.
To make progress, an issue needs an advocate. If no one cares about it,
it will languish. If the advocate is not capable of doing the work
themselves
[
http://issues.apache.org/jira/browse/LUCENE-678?page=comments#action_12443323 ]
Michael McCandless commented on LUCENE-678:
---
I believe it's correct with the line in there (ie, as committed)?
That test case is verifying that the 2nd i
[
http://issues.apache.org/jira/browse/LUCENE-678?page=comments#action_12443304 ]
Doron Cohen commented on LUCENE-678:
The patch added a call to "writer.close()" in TestLockFactory -
testFSDirectoryTwoCreates().
This is just before the 2nd a
[
http://issues.apache.org/jira/browse/LUCENE-687?page=comments#action_12443303 ]
Yonik Seeley commented on LUCENE-687:
-
Awesome stuff Michael!
This looks like it should speed up most phrase seaches. Do you have any
performance numbers?
I
[
http://issues.apache.org/jira/browse/LUCENE-573?page=comments#action_12443287 ]
Yonik Seeley commented on LUCENE-573:
-
> What do we have to do to include tha patch in the release?
IMO, the minimal amount that needs to be done is
1) map \
[
http://issues.apache.org/jira/browse/LUCENE-544?page=comments#action_12443217 ]
Karl Wettin commented on LUCENE-544:
Great stuff Matt! Thanks for the contribution! I didn't use this feature for a
while now due to my original messy patchwor
[
http://issues.apache.org/jira/browse/LUCENE-573?page=comments#action_12443214 ]
Michael Krkoska commented on LUCENE-573:
I just experienced this bug in my search. The patch works for me, though I
found it rather cumbersome to build luc
[ http://issues.apache.org/jira/browse/LUCENE-687?page=all ]
Michael Busch updated LUCENE-687:
-
Attachment: lazy_prox_skipping.patch
> Performance improvement: Lazy skipping on proximity file
>
>
>
Performance improvement: Lazy skipping on proximity file
Key: LUCENE-687
URL: http://issues.apache.org/jira/browse/LUCENE-687
Project: Lucene - Java
Issue Type: Improvement
C
On Wednesday 18 October 2006 06:21, Chris Hostetter wrote:
> : > : When custom Scorers and/or Directories need a close method, it can
> : > : also be provided by subclassing Scorer, IndexSearcher and Directory
>
> : > it seems like that would handicap adoption of new
Queries/Directories ...
> : >
[
http://issues.apache.org/jira/browse/LUCENE-365?page=comments#action_12443194 ]
Paul Elschot commented on LUCENE-365:
-
That was indeed not intentional, thanks for adding it back.
To my surprise the svn update applied cleanly on
Disjunction
37 matches
Mail list logo
