[
https://issues.apache.org/jira/browse/LUCENE-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854853#action_12854853
]
Toke Eskildsen commented on LUCENE-2380:
Working on LUCENE-2369 I essentially had
On Wed, Apr 7, 2010 at 3:27 PM, Earwin Burrfoot ear...@gmail.com wrote:
No, this doesn't make sense. The OS detects a disk full on accepting
the write into the write cache, not [later] on flushing the write
cache to disk. If the OS accepts the write, then disk is not full (ie
flushing the
[
https://issues.apache.org/jira/browse/LUCENE-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854876#action_12854876
]
Michael McCandless commented on LUCENE-2376:
OK but I suspect the root cause
Hi
I've noticed benchmark has a NoDeletionPolicy class and I was wondering if
we can move it to core. I might want to use it for the parallel index stuff,
but I think it'll also fit nicely in core, together with the other No*
classes. In addition, this class should be made a singleton.
If moving
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854882#action_12854882
]
Uwe Schindler commented on LUCENE-2074:
---
As requested on the mailing list, I will
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854885#action_12854885
]
Shai Erera commented on LUCENE-2074:
Uwe, must this be coupled with that issue? This
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854886#action_12854886
]
Uwe Schindler commented on LUCENE-2074:
---
I plan to commit this soon! So any patch
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854887#action_12854887
]
Shai Erera commented on LUCENE-2074:
bq. I plan to commit this soon!
That's great
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854890#action_12854890
]
Uwe Schindler commented on LUCENE-2074:
---
You dont need the jflex binaries in
+1
I don't think bw needs to be kept -- contrib/benchmark is allowed to change.
Mike
On Thu, Apr 8, 2010 at 5:44 AM, Shai Erera ser...@gmail.com wrote:
Hi
I've noticed benchmark has a NoDeletionPolicy class and I was wondering if
we can move it to core. I might want to use it for the
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2074:
--
Attachment: LUCENE-2074.patch
Here a new patch, with the zzBuffer reset to default
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2074:
--
Attachment: LUCENE-2074.patch
Updated also the error message about missing jflex when calling
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854899#action_12854899
]
Mark Miller commented on LUCENE-2074:
-
{quote}Uwe, must this be coupled with that
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2074:
--
Attachment: LUCENE-2074.patch
Use a separate JFlex generated Unicode 4 by Java 5 compatible
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2074:
--
Attachment: (was: LUCENE-2074.patch)
Use a separate JFlex generated Unicode 4 by Java 5
Reset zzBuffer in StandardTokenizerImpl* when lexer is reset.
-
Key: LUCENE-2384
URL: https://issues.apache.org/jira/browse/LUCENE-2384
Project: Lucene - Java
Issue Type: Sub-task
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854900#action_12854900
]
Uwe Schindler commented on LUCENE-2074:
---
Created sub-issue: LUCENE-2384
Use a
[
https://issues.apache.org/jira/browse/LUCENE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854901#action_12854901
]
Ruben Laguna commented on LUCENE-2384:
--
The mailing list discussion that originated
[
https://issues.apache.org/jira/browse/LUCENE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854902#action_12854902
]
Robert Muir commented on LUCENE-2384:
-
If tokenizers like StandardTokenizer just end
[
https://issues.apache.org/jira/browse/LUCENE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854903#action_12854903
]
Uwe Schindler commented on LUCENE-2384:
---
For JFlex this does not help as the
[
https://issues.apache.org/jira/browse/LUCENE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ruben Laguna updated LUCENE-2384:
-
Attachment: reset.diff
patch to reset the zzBuffer when the input is reseted. The code is
[
https://issues.apache.org/jira/browse/LUCENE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854905#action_12854905
]
Ruben Laguna edited comment on LUCENE-2384 at 4/8/10 11:24 AM:
[
https://issues.apache.org/jira/browse/LUCENE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854906#action_12854906
]
Robert Muir commented on LUCENE-2384:
-
bq. For JFlex this does not help as the
[
https://issues.apache.org/jira/browse/LUCENE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854908#action_12854908
]
Uwe Schindler commented on LUCENE-2384:
---
{quote}
patch to reset the zzBuffer when
[
https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854919#action_12854919
]
Jukka Zitting commented on LUCENE-1482:
---
We use SLF4J in Jackrabbit, and having logs
[
https://issues.apache.org/jira/browse/LUCENE-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854920#action_12854920
]
Shai Erera commented on LUCENE-1482:
I still think that calling isDebugEnabled is
What kind of JVM settings are you using? Lots of people index lots of
documents
without running into this, can you provide more specifics about your
indexing
settings?
On Tue, Apr 6, 2010 at 10:51 PM, Shivender Devarakonda (JIRA)
j...@apache.org wrote:
java.lang.OutOfMemoryError:Java heap
[
https://issues.apache.org/jira/browse/LUCENE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854957#action_12854957
]
Tom Burton-West commented on LUCENE-1709:
-
I am having the same issue Shai
[
https://issues.apache.org/jira/browse/LUCENE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854959#action_12854959
]
Robert Muir commented on LUCENE-1709:
-
Thanks Tom and Shai... sorry I haven't gotten
[
https://issues.apache.org/jira/browse/LUCENE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854960#action_12854960
]
Tom Burton-West commented on LUCENE-1709:
-
This may or may not be a clue to the
[
https://issues.apache.org/jira/browse/LUCENE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12854967#action_12854967
]
Robert Muir commented on LUCENE-1709:
-
Thanks Tom, this is exactly what happened to
[
https://issues.apache.org/jira/browse/LUCENE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855020#action_12855020
]
Shai Erera commented on LUCENE-1709:
Robert, I will commit the patch, seems good to do
[
https://issues.apache.org/jira/browse/LUCENE-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855022#action_12855022
]
Tom Burton-West commented on LUCENE-1709:
-
Hi Robert,
I patched Revision 931708
Move NoDeletionPolicy from benchmark to core
Key: LUCENE-2385
URL: https://issues.apache.org/jira/browse/LUCENE-2385
Project: Lucene - Java
Issue Type: Improvement
Components:
IndexWriter commits unnecessarily on fresh Directory
Key: LUCENE-2386
URL: https://issues.apache.org/jira/browse/LUCENE-2386
Project: Lucene - Java
Issue Type: Bug
Components:
[
https://issues.apache.org/jira/browse/LUCENE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2385:
---
Attachment: LUCENE-2385.patch
Move NoDeletionPolicy to core, adds javadocs + TestNoDeletionPolicy.
[
https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855131#action_12855131
]
Shai Erera commented on LUCENE-2386:
Took a look at IndexFileDeleter, and located to
IndexWriter retains references to Readers used in Fields (memory leak)
--
Key: LUCENE-2387
URL: https://issues.apache.org/jira/browse/LUCENE-2387
Project: Lucene - Java
[
https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855135#action_12855135
]
Michael McCandless commented on LUCENE-2386:
I agree: IW really should not
[
https://issues.apache.org/jira/browse/LUCENE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855136#action_12855136
]
Uwe Schindler commented on LUCENE-2385:
---
The patch does not look like you svn moved
[
https://issues.apache.org/jira/browse/LUCENE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855140#action_12855140
]
Shai Erera commented on LUCENE-2385:
I did that first, but then remembered that when I
[
https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855148#action_12855148
]
Shai Erera commented on LUCENE-2386:
Looking at IFD again, I think a boolean ctor arg
[
https://issues.apache.org/jira/browse/LUCENE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855150#action_12855150
]
Uwe Schindler commented on LUCENE-2385:
---
In general we place a list of all svn
[
https://issues.apache.org/jira/browse/LUCENE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2385:
---
Attachment: LUCENE-2385.patch
Is it better now?
Move NoDeletionPolicy from benchmark to core
[
https://issues.apache.org/jira/browse/LUCENE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855155#action_12855155
]
Shai Erera commented on LUCENE-2385:
Forgot to mention that the only move I made was
[
https://issues.apache.org/jira/browse/LUCENE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855164#action_12855164
]
Uwe Schindler commented on LUCENE-2385:
---
Yeah thats fine!
Move NoDeletionPolicy
[
https://issues.apache.org/jira/browse/LUCENE-2385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera resolved LUCENE-2385.
Resolution: Fixed
Committed revision 932129.
Move NoDeletionPolicy from benchmark to core
There is one possibility, that could be fixed:
As Tokenizers are reused, the analyzer holds a reference to the last used
Reader. The easy fix would be to unset the Reader in Tokenizer.close(). If this
is the case for you, that may be easy to do. So Tokenizer.close() looks like
this:
/** By
: Is it possible to change it? If not, what is the policy here? To open a
: new issue and close the old one?
...
: In this case, that would mean either closing this issue and opening a new one,
: or taking the discussion to the mailing list where subject headers may be
: modified as the
[
https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shai Erera updated LUCENE-2386:
---
Attachment: LUCENE-2386.patch
First stab at this. Patch still missing CHANGES entry, and I haven't
[
https://issues.apache.org/jira/browse/LUCENE-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2074:
--
Attachment: LUCENE-2074.patch
New patch with replacement of deprecated TermAttribute -
But, IW doesn't let you hold on to checkpoints... only to commits.
Ie SnapshotDP will only see actual commit/close calls, not
intermediate checkpoints like a random segment merge completing, a
flush happening, etc.
Or... maybe you would in fact call commit frequently from the main
threads
Actually Toke opened a new issue (LUCENE-2369) for the new approach to
Locale-based sorting... I think we should leave the existing issue as
the single-segment optimization (it's a separate issue).
Mike
On Thu, Apr 8, 2010 at 6:06 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: Is it
[
https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855215#action_12855215
]
Michael McCandless commented on LUCENE-2386:
I think the patch is good Shai.
On Thu, Apr 8, 2010 at 6:21 PM, Earwin Burrfoot ear...@gmail.com wrote:
But, IW doesn't let you hold on to checkpoints... only to commits.
Ie SnapshotDP will only see actual commit/close calls, not
intermediate checkpoints like a random segment merge completing, a
flush happening, etc.
Good point. I meant the model at the document level: i.e. what
milestones does a document go through in its life cycle. Today:
created -- deleted
With incremental updates:
created -- update1 -- update2 -- deleted
I think what I'm trying to say is that this second threaded sequence
of state
[
https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855265#action_12855265
]
Shai Erera commented on LUCENE-2386:
bq. Maybe change testImmediateDiskFull to set max
Hi
I've noticed that TestCodecs takes an insanely long time to run on my
machine - between 35-40 seconds. Is that expected?
The reason why it runs so long, seems to be that its threads make (each)
4000 iterations ... is that really required to ensure correctness?
Shai
Here is a Java unit test that uses the LogByteSizeMergePolicy to
control the maximum size of segment files during indexing. That is, it
tries. It does not succeed. Will someone who truly understands the
merge policy code please examine it. There is probably one tiny
parameter missing.
It adds 20
I'm not sure .. but did you set the RAMBufferSizeMB on IWC? Doesn't look
like it, and the default is 16 MB, which can explain why it doesn't flush
before that.
Shai
On Fri, Apr 9, 2010 at 8:01 AM, Lance Norskog goks...@gmail.com wrote:
Here is a Java unit test that uses the
[
https://issues.apache.org/jira/browse/LUCENE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12855277#action_12855277
]
Shai Erera commented on LUCENE-2386:
Apparently, there are more tests that fail ...
[
https://issues.apache.org/jira/browse/LUCENE-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shivender Devarakonda updated LUCENE-2376:
--
Attachment: CheckIndex_JavaHeapOOM.txt
CheckIndex output for JavaHeapOOM
[
https://issues.apache.org/jira/browse/LUCENE-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shivender Devarakonda updated LUCENE-2376:
--
Attachment: CheckIndex_PermGenSpaceOOM.txt
If we start our product with
63 matches
Mail list logo
