[
http://issues.apache.org/jira/browse/LUCENE-697?page=comments#action_12445795 ]
Doron Cohen commented on LUCENE-697:
An updated version of this patch - sloppy_phrase_skipTo.patch2.
I modified QueryUtils.java (test util) to test all the seq
[ http://issues.apache.org/jira/browse/LUCENE-697?page=all ]
Attachment: sloppy_phrase_skipTo.patch2
> Scorer.skipTo affects sloppyPhrase scoring
> --
>
> Key: LUCENE-697
> URL: http://issues.apache.org/jira/browse/
Not having to assign index readers a write permission in the index dir is a
nice feature, I didn't think of it that way.
I looked at having it the other way around - i.e. that by default locks
would be maintained in the index dir and only when inadequate - like the
readers/writers scenario, allow
I you may be overcomplicating the lock design. Unix never had any OS
file locking at all (until Windows came around...).
If you are going to use Lucene in a high performing multi-user/multi-
server environment, having the Lucene server process control the
locks (i.e. move Lucene API into a s
[ http://issues.apache.org/jira/browse/LUCENE-687?page=all ]
Michael Busch updated LUCENE-687:
-
Attachment: lazy_prox_skipping2.patch
Yonik,
thanks for committing the patch!
About the performance tests you did: I think even on a RAMDirectory the patch
: Doug explains the rationale here:
:
: http://xrl.us/svsz (Link to mail-archives.apache.org)
That rationale makes a lot of sense for FSDirectory/SimpleLockFactory to
use by default (since it already doesn't work in a distributed disk
system like NFS) but as we start getting other Directory/LockF
On Oct 30, 2006, at 3:12 PM, Doron Cohen wrote:
This would be avoided if index locks are maintained in the index
folder. I
searched the lists for previous discussions on this 'design
decision' -
i.e. where the index locks reside - found none. Wouldn't it simplify
matters to have the locks i
(extracted from issue 665 (turned to be non related to that issue).)
In NFS or other shared fs situations, Locks are maintained in a specified
folder, but a lock file name is derived from the full path of the index
dir, actually the canonical name of this dir. So, if the same index is
accessed by
Yonik Seeley wrote:
Yes, the JavaDocs for Lucene, Solr, Hadoop, Nutch are populated during
the nightly build process.
Actually the've typically been the current release. Hadoop updated its
javadocs nightly before its first release, but now they're the current
release. Solr may update it's n
On 10/30/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:>
i thought there was a cron that took care of doing that on a regular
basis?
Yes, the JavaDocs for Lucene, Solr, Hadoop, Nutch are populated during
the nightly build process.
...perhaps the same cron that does/did the nightly builds? ...
> I _believe_ javadocs are for the latest released version (2.0).
I thought not, because they are titled "Lucene 2.1-dev API", and also
because they contain, e.g., LockFactory, which I think was not in 2.0.
-
To unsubscribe, e-m
: Hmmm, I updated them when I added in scoring docs (I kept the old
: directories around, though) and they were based on trunk at the time
: I did it. I wasn't aware of them being the latest released version,
: but I can restore them to that easily enough.
I believe they have allways been based
By the looks of http://wiki.apache.org/jakarta-lucene/ReleaseTodo it
should be the latest release.However, this breaks some of the
links in the scoring documentation. Shall I revert the javadocs or
should I revert the scoring docs or should we just leave things as is
for now with the a
Hmmm, I updated them when I added in scoring docs (I kept the old
directories around, though) and they were based on trunk at the time
I did it. I wasn't aware of them being the latest released version,
but I can restore them to that easily enough.
It might be nice to have two versions of
: I _believe_ javadocs are for the latest released version (2.0).
No ... they say "Lucene 2.1-dev API" in the title, and where last modified
on October 10th ... several post 2.0 things are listed (like Fieldable).
Something definitely seems to have gone wrong in teh nightly generation
... but i
[ http://issues.apache.org/jira/browse/LUCENE-687?page=all ]
Yonik Seeley resolved LUCENE-687.
-
Fix Version/s: 2.1
Resolution: Fixed
Assignee: Yonik Seeley
Reviewed and committed. Thanks Michael!
> Performance improvement: Lazy skipping
[ http://issues.apache.org/jira/browse/LUCENE-703?page=all ]
Mark Harwood updated LUCENE-703:
Attachment: patch.diff
Change to QueryParser and associated JUnit test
> Change QueryParser to use ConstantScoreRangeQuery in preference to RangeQuery
> by de
Change QueryParser to use ConstantScoreRangeQuery in preference to RangeQuery
by default
Key: LUCENE-703
URL: http://issues.apache.org/jira/browse/LUCENE-703
Pro
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12445724 ]
Doron Cohen commented on LUCENE-665:
> Odd that just by using native locking, it stopped your issues.
Agree. I did not expect that to happen, since indeed I sa
I _believe_ javadocs are for the latest released version (2.0).
Otis
- Original Message
From: Doron Cohen <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Monday, October 30, 2006 5:03:49 PM
Subject: site javadocs and resolved issue 678
I just noticed that current javadocs in
h
I just noticed that current javadocs in
http://lucene.apache.org/java/docs/api/index.html do not contain
NativeFSLockFactory, or other changes related to resolved issue 678.
Shouldn't it?
Thanks,
Doron
-
To unsubscribe, e-mail:
If we can, we should hold off on any INFRA requests for a little while anyway...
they still look pretty swamped right now due to the recent move.
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server
On 10/30/06, Steven Parkes <[EMAIL PROTECTED]> wrote:
Oh, well, i
Oh, well, it was worth a shot:
>From http://www.apache.org/dev/reporting-issues.html:
All requests for resources must come from a PMC member and the
PMC must be copied.
For what it's worth, the instructions for creating a new wiki (there's
nothing explicit about changing the wiki) are:
[
http://issues.apache.org/jira/browse/LUCENE-687?page=comments#action_12445709 ]
Yonik Seeley commented on LUCENE-687:
-
Oh, those synthetic tests were done on a RAMDirectory, so that also reduces the
benefits of your patch.
> Performance i
[
http://issues.apache.org/jira/browse/LUCENE-667?page=comments#action_12445708 ]
Steven Parkes commented on LUCENE-667:
--
Here's the text from the javacc FAQ:
2.2 Can I modify the generated files?
Modifying any generated files should be ge
[
http://issues.apache.org/jira/browse/LUCENE-687?page=comments#action_12445707 ]
Yonik Seeley commented on LUCENE-687:
-
I did some quick synthetic tests of my own Java5 -server
100,000 documents, 25 different terms, prob of term in doc
: commited to) and have new (optional) fields indicating what FV
: has been
: used for in the past:
: How significant is are the changes resulting from this issue?
: A - major bug fix; no api changes; should be put into an
: X.Y.Z
: releases ASAP
:
Otis Gospodnetic wrote:
Regarding your payloads example and 2.1 vs. 3.0, there is a simpler approach,
and one that we have
>pretty much (unintentionally?) been using. Larger chunks of work take
longer,
need more eyes to check them, to test them locally, iron out bugs, etc. and
finally
>app
Therefore, while this work is in progress, it's all done via
patches in JIRA,
and people's local repositories.
This is pretty close to a separate "payloads" branch. That just provides
a shared branch, should the number of people working on that code line
require it for better com
: Subject: [jira] Commented: (LUCENE-687) Performance improvement: Lazy
: skipping on proximity file
Speaking purely out of paranoia: we've seen a few bugs pop up in the last
year that only manifest themselves in multi-segment indexes, so they sneak
past simple unit tests, or unit tests that
[
http://issues.apache.org/jira/browse/LUCENE-687?page=comments#action_12445683 ]
Michael Busch commented on LUCENE-687:
--
I made some performance experiments with phrase searches. For every query I
measured the search time as well as the nu
[
http://issues.apache.org/jira/browse/LUCENE-665?page=comments#action_12445540 ]
Michael McCandless commented on LUCENE-665:
---
Odd that just by using native locking, it stopped your issues. Lucene (without
lock-less commits) does quit
[
http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12445537 ]
Michael McCandless commented on LUCENE-555:
---
Phew! OK, thanks for bringing closure to this.
> Index Corruption
>
>
> Ke
[
http://issues.apache.org/jira/browse/LUCENE-555?page=comments#action_12445520 ]
Tero Hagström commented on LUCENE-555:
--
We managed to identify the source of the index corruption. A system
administrator manually removed a file from the ind
34 matches
Mail list logo
