[
https://issues.apache.org/jira/browse/LUCENE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474924
]
Doron Cohen commented on LUCENE-808:
[ moving discussion back to JIRA ]
Ning Li wrote:
> On 2/21/07, Doron Cohe
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Vasiliev updated LUCENE-769:
--
Description:
It's a small addition to Lucene that significantly lowers memory consumption
and
On 2/21/07, Doron Cohen <[EMAIL PROTECTED]> wrote:
> > The downside is another complexity increase though.
I think complexity can be divided in two:
(1) more complex synchronization and data-manipulation/accounting
(2) multi-threading.
The multi-threading becoming part of and responsibility of
> > The downside is another complexity increase though.
I think complexity can be divided in two:
(1) more complex synchronization and data-manipulation/accounting
(2) multi-threading.
The multi-threading becoming part of and responsibility of Lucne
seems quite a change to me. Lucene's being sing
On 2/21/07, Doron Cohen (JIRA) <[EMAIL PROTECTED]> wrote:
Imagine the application and Lucene could talk, with the current
implementation we could hear something like this: ...
However, there could be multiple threads updating the same index. For
example, thread 1 deletes the term "id:5" twice,
I think when you start discussing background threads you need to
think server environment.
It is fairly trivial there. I have pushed to move Lucene in that
direction, rather than the multiple client accessing a shared
resource via a network filesystem. No decent server product works
this
On 2/21/07, Doron Cohen <[EMAIL PROTECTED]> wrote:
Ning Li wrote:
> There are three main challenges in enabling concurrent merge:
> 1 a robust merge policy
> 2 detect when merge lags document additions/deletions
> 3 how to slow down document additions/deletions (and amortize
> the cost
Ning Li wrote:
> There are three main challenges in enabling concurrent merge:
> 1 a robust merge policy
> 2 detect when merge lags document additions/deletions
> 3 how to slow down document additions/deletions (and amortize
> the cost) when merge falls behind
I wonder what it means for
I agree, that is why I suggested using the queue. You will add new
segments to be merged to a queue. The merge thread pulls segments
form the queue when it is free to do so. The addDocument() creates a
new segment and adds it to the queue. If the queue is full, the add
to the queue will blo
On Tue, Feb 20, 2007, Ning Li wrote about "Concurrent merge":
> I think it's possible for another version of IndexWriter to have
> a concurrent merge thread so that disk segments could be merged
> while documents are being added or deleted.
> This would be beneficial not only because it will improv
On Tue, Feb 20, 2007, robert engels wrote about "Re: Concurrent merge":
> What about a queue of segments to merge. The add document will add
> segments to the queue, if the queue contains too many segments it
> blocks.
>
> Another thread reads the segments from the queue and merges them.
>
>
Great Andrzej, that fixed it. Thanks.
Antony
Andrzej Bialecki wrote:
Antony Bowesman wrote:
With the luke.jar download, it throws an Exception
java.lang.NoClassDefFoundError: org/apache/lucene/index/IndexGate
Fixed - I uploaded an updated jar. Sorry for the problem.
---
Antony Bowesman wrote:
With the luke.jar download, it throws an Exception
java.lang.NoClassDefFoundError: org/apache/lucene/index/IndexGate
Fixed - I uploaded an updated jar. Sorry for the problem.
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __
Antony Bowesman wrote:
Hi Andrzej,
Thanks for this - it's a great tool.
With the luke.jar download, it throws an Exception
java.lang.NoClassDefFoundError: org/apache/lucene/index/IndexGate
at org.getopt.luke.Luke.getIndexFileNames(Unknown Source)
at org.getopt.luke.Luke.showFil
Hi Andrzej,
Thanks for this - it's a great tool.
With the luke.jar download, it throws an Exception
java.lang.NoClassDefFoundError: org/apache/lucene/index/IndexGate
at org.getopt.luke.Luke.getIndexFileNames(Unknown Source)
at org.getopt.luke.Luke.showFiles(Unknown Source)
Chris Hostetter wrote:
... if because of jira settings we are forced to choose between:
1) deletes are completely impossible
2) only members of "lucene-developers" jira group can delete
3) people can delete their own attachments
...i would choose #1 for safety (better to have a ton of c
Hi Erik, Hi everybody,
> Anyone gonna tackle this?
>
> I personally have never used Maven or the POM stuff, and have never
> published our releases to the repository. Could this step be automated
> somehow? Volunteers?
Should not be that hard to put 2 files somewhere
(org/apache/lucene/lucene-h
Hi all,
I'm happy to announce that a new version of Luke - the Lucene Index
Toolbox - is now available. As usually, you can get it from:
http://www.getopt.org/luke
Highlights of this release:
* support for Lucene 2.1.0 release and earlier
* pagination of search results
* support for many
: Yes. It is controlled by the "Delete Issues" permission: "Ability to
: delete issues, comments and attachments." Lucene Java uses Jira's
: Standard Permissions, and under those, the Contributor role has this
: permission. We can switch Lucene Java to use a clone of Standard
: Permissions call
Yonik Seeley wrote:
I don't think most of us can see JIRA roles, so I don't know how they
map to the groups like lucene-developer, but I think committers (or
the lucene-developers JIRA group) still need removal privs (to remove
spam, IP issues, *real* removal requests, etc).
Sorry. For Lucene
[
https://issues.apache.org/jira/browse/LUCENE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guy Loewy resolved LUCENE-809.
--
Resolution: Invalid
Classes were moved to the queries contrib jar
> No source or classes for the simil
On 2/21/07, Doug Cutting <[EMAIL PROTECTED]> wrote:
Michael McCandless wrote:
> Is this (ability to delete patches) something we can disable in Jira?
Yes. It is controlled by the "Delete Issues" permission: "Ability to
delete issues, comments and attachments." Lucene Java uses Jira's
Standard
Michael McCandless wrote:
Is this (ability to delete patches) something we can disable in Jira?
Yes. It is controlled by the "Delete Issues" permission: "Ability to
delete issues, comments and attachments." Lucene Java uses Jira's
Standard Permissions, and under those, the Contributor role
On Wed, 21 Feb 2007 15:04:01 -0500, "Yonik Seeley" <[EMAIL PROTECTED]>
said:
> As a general rule, I don't think we should be removing attachments (of
> code) on JIRA issues.
+1
I've been hit by this in the past when I had wanted to diff the original
patch against the new one to see details on wh
+1 We should not generally remove obsolete attachments in Jira.
Doug
Yonik Seeley wrote:
As a general rule, I don't think we should be removing attachments (of
code) on JIRA issues.
- it represents a loss of code... it's not like subversion where you
can go back in time. earlier patches can a
21 feb 2007 kl. 20.55 skrev Yonik Seeley:
I think some of the attachments that were deleted were uploaded by
robert engels
not just Artem Vasiliev (the person who requested deletion).
Well I feel silly now.
-
To unsubscrib
And another reason I just thought of... it provides better tracking of IP.
Once something goes in JIRA, multiple people might start contributing
ideas. If you remove all previous versions, there is no record of the
original submission, or who contributed what to the final.
-Yonik
On 2/21/07, Yo
As a general rule, I don't think we should be removing attachments (of
code) on JIRA issues.
- it represents a loss of code... it's not like subversion where you
can go back in time. earlier patches can also sometimes be simpler in
places, or can take a different approach, and there can be value
[
https://issues.apache.org/jira/browse/LUCENE-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-793.
---
Resolution: Fixed
Fix Version/s: 2.2
OK, I just committed this. I stuck with
[
https://issues.apache.org/jira/browse/LUCENE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474808
]
Doron Cohen commented on LUCENE-808:
Ning Li wrote:
> The code correctly reflects its designed semantics:
> numB
On 2/21/07, Karl Wettin (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-769:
---
Attachment: (was: IndexReaderUtils.java)
I
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-769:
---
Attachment: (was: QueryFilter.java)
> [PATCH] Performance improvement for some cases of sorted se
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-769:
---
Attachment: (was: DocCachingSorting.patch)
> [PATCH] Performance improvement for some cases of so
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-769:
---
Attachment: (was: IndexReaderUtils.java)
> [PATCH] Performance improvement for some cases of sort
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-769:
---
Attachment: (was: DocCachingSorting.patch)
> [PATCH] Performance improvement for some cases of so
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-769:
---
Attachment: (was: StoredFieldSorting.patch)
> [PATCH] Performance improvement for some cases of s
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-769:
---
Attachment: (was: selfContained.patch)
> [PATCH] Performance improvement for some cases of sorted
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-769:
---
Attachment: (was: selfContained.patch)
> [PATCH] Performance improvement for some cases of sorted
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Wettin updated LUCENE-769:
---
Attachment: (was: selfContained.patch)
> [PATCH] Performance improvement for some cases of sorted
[
https://issues.apache.org/jira/browse/LUCENE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guy Loewy updated LUCENE-809:
-
Fix Version/s: 2.1
> No source or classes for the similarity contrib
> --
No source or classes for the similarity contrib
---
Key: LUCENE-809
URL: https://issues.apache.org/jira/browse/LUCENE-809
Project: Lucene - Java
Issue Type: Bug
Affects Versions: 2.1
[
https://issues.apache.org/jira/browse/LUCENE-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Artem Vasiliev updated LUCENE-769:
--
Description:
The attachment №5 from 31 Jan is the last and the whole patch for this issue.
Guy
On 2/21/07, Ning Li <[EMAIL PROTECTED]> wrote:
I agree that the current blocking model works for some applications,
especially if the indexes are batch built.
But other applications, e.g. with online indexes, would greatly
benefit from a non-blocking model. Most systems that merge data
support b
The code correctly reflects its designed semantics:
numBufferedDeleteTerms is a simple sum of terms passed to
updateDocument or deleteDocuments.
If the first of two successive calls to the same term should be
considered no op if no docs were added in between, shouldn't the first
also be considere
[
https://issues.apache.org/jira/browse/LUCENE-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll reassigned LUCENE-791:
--
Assignee: Grant Ingersoll
> Update the Wiki
> ---
>
> Key:
The point I was trying to make is that even if you use a background
thread for merging, that at some point it may block, if the document
additions out-pace the merging.
On Feb 21, 2007, at 11:47 AM, Ning Li wrote:
I agree that the current blocking model works for some applications,
especial
[
https://issues.apache.org/jira/browse/LUCENE-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474773
]
Doug Cutting commented on LUCENE-791:
-
To summarize: someone should file an issue in the Infrastructure Jira
req
I agree that the current blocking model works for some applications,
especially if the indexes are batch built.
But other applications, e.g. with online indexes, would greatly
benefit from a non-blocking model. Most systems that merge data
support background merges. As long as we keep it simple (
Chris Hostetter wrote:
: since we have different sets of committers for different sub-projects,
: it probably makes more sense to have per-subproject KEYS files. That
: way folks can add their own keys without altering our current permission
: scheme.
yeah, it would certianly be a "paradigm shi
On 2/20/07, karl wettin <[EMAIL PROTECTED]> wrote:
Could the reader per segment be replaced by one single MultiReader
created by the original indexDeleterFactory()? Or are the segments
partially the RAMDirectory of the writer, partially the persistent
index?
All segments are disk segments. Howe
[
https://issues.apache.org/jira/browse/LUCENE-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otis Gospodnetic updated LUCENE-759:
Attachment: LUCENE-759.patch
Here is the proper version. This one is essentially the
Luce
[
https://issues.apache.org/jira/browse/LUCENE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen reassigned LUCENE-808:
--
Assignee: Doron Cohen
> bufferDeleteTerm in IndexWriter might flush prematurely
> -
[
https://issues.apache.org/jira/browse/LUCENE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Doron Cohen updated LUCENE-808:
---
Attachment: successive_bufferDeleteTerm.patch
> bufferDeleteTerm in IndexWriter might flush premature
bufferDeleteTerm in IndexWriter might flush prematurely
---
Key: LUCENE-808
URL: https://issues.apache.org/jira/browse/LUCENE-808
Project: Lucene - Java
Issue Type: Bug
Components
54 matches
Mail list logo
