[
https://issues.apache.org/jira/browse/LUCENE-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542356
]
Paul Elschot commented on LUCENE-1051:
--
This has been somewhere far down on my todo list for quite a while, so
[
https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542333
]
Michael Busch commented on LUCENE-743:
--
{quote}
So how about a public IndexReader.flush() method
{quote}
Since
[
https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542332
]
Michael Busch commented on LUCENE-743:
--
{quote}
* You should also close fieldsReader when referencedSegmentR
[
https://issues.apache.org/jira/browse/LUCENE-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542322
]
Michael Busch commented on LUCENE-1051:
---
I'm planning to commit this tomorrow... any objections? Did anyone lo
[
https://issues.apache.org/jira/browse/LUCENE-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542261
]
Doug Cutting commented on LUCENE-1044:
--
> Maybe we should leave the default as false for now?
Perhaps for the
You might be misreading the results for the mac mini. If you compare
the mac mini with the sync pro, they are what is expected, the
unsync'd is roughly the same as the sync'd.
It might be that Apple configures the driver to not allow lazy writes
for the internal drive? Maybe for reliability
[
https://issues.apache.org/jira/browse/LUCENE-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reopened LUCENE-1044:
OK I ran sync/nosync tests across various platforms/IO system. In
each case I ran the
[
https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542212
]
Yonik Seeley commented on LUCENE-743:
-
So how about a public IndexReader.flush() method so that one could also re
[
https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542201
]
Michael McCandless commented on LUCENE-743:
---
{quote}
Awesome! Thanks so much for pointing me there, Mike! I
[
https://issues.apache.org/jira/browse/LUCENE-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1052:
---
Attachment: LUCENE-1052.patch
Attached patch derived from Doug's & Chuck's patches f
"Chris Hostetter" <[EMAIL PROTECTED]> wrote:
>
> : When I load an issue I see tons of verbose text (eg
> : issue.operations.attach) instead of the normal links (Attach...).
>
> verified ... looks like resource bundle stirngs for I18N and it's showing
> the key and not the value.
OK. It seems
: When I load an issue I see tons of verbose text (eg
: issue.operations.attach) instead of the normal links (Attach...).
verified ... looks like resource bundle stirngs for I18N and it's showing
the key and not the value.
: More scary, when I click on an attachment to download it I get "error
When I load an issue I see tons of verbose text (eg issue.operations.attach)
instead of the normal links (Attach...).
More scary, when I click on an attachment to download it I get "error
project.does.not.exist.desc".
Does anyone else see this?
Mike
--
The user list is the appropriate spot, but this brings up a
discussion point.
The "norms" will require 1 byte per document, so you will need at
least 512 M for the heap.
Start the java process with -Xmx512m and see what happens.
Depending on what you are doing you might be able to "omit th
[
https://issues.apache.org/jira/browse/LUCENE-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved LUCENE-1053.
-
Resolution: Invalid
Lucene Fields: (was: [New])
Hi Lars,
Generally we recommen
OutOfMemoryError on search in large, simple index
-
Key: LUCENE-1053
URL: https://issues.apache.org/jira/browse/LUCENE-1053
Project: Lucene - Java
Issue Type: Bug
Components: Search
I was just trying to figure out why reopen() could fail ???
It would seem that on unix/linux the files could always be read
(since they don't delete until last close), and on Windows they would
be there (since they can't be deleted because they are open).
When "deleting segments", it would
Add an "termInfosIndexDivisor" to IndexReader
-
Key: LUCENE-1052
URL: https://issues.apache.org/jira/browse/LUCENE-1052
Project: Lucene - Java
Issue Type: Improvement
Components: Index
"Chuck Williams" <[EMAIL PROTECTED]> wrote:
> Doug Cutting wrote on 11/07/2007 09:26 AM:
> > Hadoop's MapFile is similar to Lucene's term index, and supports a
> > feature where only a subset of the index entries are loaded
> > (determined by io.map.index.skip). It would not be difficult to add
I've become lost in this thread.
It started with the unit test in the reopen patch, suddenly jumped to
NFS and lockless commits, then sync() got pulled in as well.
The retry logic (part of lockless commits) already handles this case
of a segments file being partially written & falling back to th
20 matches
Mail list logo
