[ http://issues.apache.org/jira/browse/LUCENE-480?page=all ]
Yonik Seeley closed LUCENE-480:
---
Resolution: Invalid
Assign To: Yonik Seeley
No problem... glad to hear it will be an easy fix :-)
> NullPointerException during IndexWriter.mergeSegmen
[
http://issues.apache.org/jira/browse/LUCENE-480?page=comments#action_12359810 ]
Jeremy Calvert commented on LUCENE-480:
---
Apparently my hardware or filesystem is having some difficulties, which could
be the reason the fieldsStream is corrupt. I apolo
I
modified MemoryLRUCache to use the attached ConcurrentHashMap.java and ran under
1.4.2_10
filesize is 4194304
non-cached time = 11140, avg = 0.01114
non-cached threaded (3 threads) time = 35485, avg = 0.011828
cached time = 6109, avg = 0.006109
cache hits 996138
cache misses 386
[ http://issues.apache.org/jira/browse/LUCENE-479?page=all ]
Doug Cutting resolved LUCENE-479:
-
Fix Version: 1.9
Resolution: Fixed
I committed this. Thanks!
> MultiReader.numDocs incorrect after undeleteAll
> -
Most of the CPU time is actually used during the synchronization with multiple threads. I hacked together a version of MemoryLRUCache that used a ConcurrentHashMap from JDK 1.5, and it was another 50% faster ! At a minimum, if the ReadWriteLock class was modified to use the 1.5 facilities some si
[
http://issues.apache.org/jira/browse/LUCENE-480?page=comments#action_12359755 ]
Jeremy Calvert commented on LUCENE-480:
---
A little more data:
int fieldNumber = fieldsStream.readVInt();
on line 68 of FieldsReader.java results in fieldNumber =
[
http://issues.apache.org/jira/browse/LUCENE-480?page=comments#action_12359752 ]
Jeremy Calvert commented on LUCENE-480:
---
Sure, let me try and put that together.
> NullPointerException during IndexWriter.mergeSegments
> --
[
http://issues.apache.org/jira/browse/LUCENE-480?page=comments#action_12359750 ]
Yonik Seeley commented on LUCENE-480:
-
Is this possible to reproduce in a testcase you can add here?
FieldInfo should never be null AFAIK, so I'd rather get to the root ca
As a follow-up...
The real performance benefit comes in a shared server environment, where the
Lucene process runs along side other processes - i.e. competes for the use
of the OS file cache. Since the Lucene process can be configured with a
dedicated memory pool, using facilities like NioFile all
NullPointerException during IndexWriter.mergeSegments
-
Key: LUCENE-480
URL: http://issues.apache.org/jira/browse/LUCENE-480
Project: Lucene - Java
Type: Bug
Components: Index
Versions: CVS Nightly - Specify
I finally got around
to writing a testcase to verify the numbers I presented. The following testcase
and results are for the lowest level disk operations. On my machine reading from
the cache, vs. going to disk (even when the data is in the OS cache) is 30%-40%
faster. Since Lucene makes ext
11 matches
Mail list logo
