By a lot of the comments in these threads, it seems that people are
accessing their Lucene indexes via NFS (or some other network protocol).
Why not just use a dedicated server with an HTTP/TCP listener and let
it respond to Lucene queries.
I have to believe it would be orders of magnitude
On 9/14/06, Michael McCandless <[EMAIL PROTECTED]> wrote:
> If it will happen so rarely, make it simpler and go directly for
> segments_(N-1)... (treat it like your previous plan if segments_N.done
> hadn't been written yet).
Yes, true, we could just fall back to the prior segments_(N-1) file in
Yonik Seeley wrote:
Good point! A reader could easily know that's it's dealing with an
unfinished segments file (since the file says how many segments it
has) and then sleep/retry until the file completes, which should be a
rare event. Note that such contention in the current Lucene (ie, on
th
> If nothing else we would be interested in at least being able to extend
Document, which is currently declared final. (Anyone know the performance gains on
declaring a class final?)
Some of the classes are declared final due to performance issues in
previous vm versions < 1.4 but not all of
On Thu, 2006-09-14 at 15:13 -0500, robert engels wrote:
>
> Doug is not talking about java serialization, he is talking about
> general serialization used to store a Document in an Index.
Ahh, I see. That makes much more sense.
---
not being inpatient, just asking if all holes are covered, Matcher rocks and
I'd like to clean up a lot of mess we created in our local copy in order to
simulate what Matcher will permit us to do in really elegant way...
if being patient is all what it takes, cool ;)
- Original Message
Doug is not talking about java serialization, he is talking about
general serialization used to store a Document in an Index.
On Sep 14, 2006, at 3:00 PM, Karl Wettin (JIRA) wrote:
[ http://issues.apache.org/jira/browse/LUCENE-671?
page=comments#action_12434791 ]
Karl Wettin commented o
[
http://issues.apache.org/jira/browse/LUCENE-671?page=comments#action_12434791 ]
Karl Wettin commented on LUCENE-671:
Cutting:
> To make Documents fully-subclassible one would need to make their
> serialization extensible.
I find this a b
[
http://issues.apache.org/jira/browse/LUCENE-671?page=comments#action_12434782 ]
Doug Cutting commented on LUCENE-671:
-
The final declaration is not for performance. It is to keep folks from
thinking, if they subclass Document, that instan
[
http://issues.apache.org/jira/browse/LUCENE-671?page=comments#action_12434769 ]
Chris commented on LUCENE-671:
--
After some digging:
http://www-128.ibm.com/developerworks/java/library/j-jtp1029.html
If these classes are declared final for perform
[
http://issues.apache.org/jira/browse/LUCENE-584?page=comments#action_12434763 ]
Paul Elschot commented on LUCENE-584:
-
> Do you, or someone else see now things to be done before commiting this?
Yes. In the steps listed here:
http://wiki.ap
[ http://issues.apache.org/jira/browse/LUCENE-672?page=all ]
Yonik Seeley closed LUCENE-672.
---
Fix Version/s: 2.1
Resolution: Fixed
I just committed
http://issues.apache.org/jira/secure/attachment/12340475/newMergePolicy.Sept08.patch
Thanks for the
[ http://issues.apache.org/jira/browse/LUCENE-672?page=all ]
Yonik Seeley updated LUCENE-672:
Issue Type: New Feature (was: Bug)
Affects Version/s: 2.0.0
Description:
New merge policy developed in the course of
http://issues.apache
new merge policy
Key: LUCENE-672
URL: http://issues.apache.org/jira/browse/LUCENE-672
Project: Lucene - Java
Issue Type: Bug
Components: Index
Reporter: Ning Li
Today, applications have to open/close
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12434751 ]
Yonik Seeley commented on LUCENE-565:
-
I also did a quick indexing performance test w/ Solr:
maxBufferedDocs=100, mergeFactor=4, did 100K random overwriting ad
On 9/14/06, Chris (JIRA) <[EMAIL PROTECTED]> wrote:
If nothing else we would be interested in at least being able to extend
Document, which is currently declared final. (Anyone know the performance gains
on declaring a class final?)
According to this, not much:
http://www-128.ibm.com/develope
FYI: Fieldable is an interface. Field is indeed final, but
AbstractField implements most everything in Fieldable and is not
final, so if you want to customize, just be aware of the small issues
with Document.getFields() method versus Document.getFieldables()
-Grant
On Sep 14, 2006, at 11
[ http://issues.apache.org/jira/browse/LUCENE-671?page=all ]
Chris updated LUCENE-671:
-
Attachment: HashDocument.java
> Hashtable based Document
>
>
> Key: LUCENE-671
> URL: http://issues.apache.org/jira/b
[ http://issues.apache.org/jira/browse/LUCENE-671?page=all ]
Chris updated LUCENE-671:
-
Attachment: TestBenchDocuments.java
> Hashtable based Document
>
>
> Key: LUCENE-671
> URL: http://issues.apache.org/
Hashtable based Document
Key: LUCENE-671
URL: http://issues.apache.org/jira/browse/LUCENE-671
Project: Lucene - Java
Issue Type: Improvement
Components: Index, Search
Affects Versions: 2.0.0, 1.9
On 9/14/06, Michael McCandless <[EMAIL PROTECTED]> wrote:
Yonik Seeley wrote:
>> > >> But, I'm still renaming segments_N.new -> segments_N,
>> > >
>> > > Hmmm, remind me why you need the .new file? Why can't you just
>> create
>> > > segments_N after you are finished writing all of the segments?
: Even though I don't agree with this patch... 100ms is WAY TOO long
: for a highly interactive index.
agreed.
: > then, it is encouraging that similar retry logic is working for other
: > projects, and that the retry is both rare and short.
the examples of other projects I've seen mentioned ar
: We could retry only for IOExceptions, possibly only those specifying
: "access denied" in their root cause message. This would narrow the range of
: cases the retry logic is applied. In fact the first version had this
: narrowing logic, but it was removed after a comment uncomfortable with
: rel
Yonik Seeley wrote:
> >> But, I'm still renaming segments_N.new -> segments_N,
> >
> > Hmmm, remind me why you need the .new file? Why can't you just
create
> > segments_N after you are finished writing all of the segments?
>
> Because there could be a reader that tries to read the file before
[
http://issues.apache.org/jira/browse/LUCENE-584?page=comments#action_12434637 ]
Eks Dev commented on LUCENE-584:
Paul,
What is next now, we did on our app enough experiments and are now sure that
this patch causes no incompatibilities.
We als
25 matches
Mail list logo
