Hello Robert,
thanks for showing interest in this case. Find my answer below.
On 23.07.2014 12:58, Robert Muir wrote:
On Wed, Jul 23, 2014 at 6:03 AM, Harald Kirsch
<harald.kir...@raytion.com> wrote:
Hi,
below is an exception I get from one Solr core. According to
https://issues.apache.org/jira/browse/LUCENE-5617 the check that leads to
the exception was introduced recently.
Two things are worth mentioning:
a) contrary to the expectation expressed in the message (file truncated?),
the actual file length is *greater* than the expected length.
b) the actual length is 2966208512=0xB0CC_C000 which looks like rounded up
to a page size of 4096 bytes.
The code leading to the exception is
(http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/codecs/compressing/CompressingStoredFieldsReader.java?view=markup&pathrev=1592731)
if (maxPointer + CodecUtil.footerLength() != fieldsStream.length()) {
throw new CorruptIndexException("Invalid fieldsStream maxPointer (file
truncated?): maxPointer=" + maxPointer + ", length=" +
fieldsStream.length());
}
Without delving further into the code, can anyone comment on the chance this
is actually a bug? Should the test possibly be '<' instead of '!=' because
fieldsStream.length() is an OS-backed size that may report the fully
allocated disk space rounded upwards to 4k pages? (Just guessing?)
Its quite clear what length() should return, and thats the exact size
of the file.
Somehow, unfortunately your index became corrupt.
If you don't mind, can you describe a little of the environment your
machine is running on?
particularly operating system version, filesystem type, and the output
of 'java -version'
(As a side note: after truncating the file to the expected size+16, at
least the core starts up again. Have not tested anything else yet.)
Here are the details of the environment:
% cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
This is a Xen-VM.
File system is xfs hosted on a corporate file share somewhere.
% java -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
The machine has 32 GB RAM, index size on disk and mapped into memory
(VIRT) is 210 GB. The other 9 cores run flawlessly, this core ran
flawlessly until today.
The corrupted files (we found a second one) are *.fdt. They contain only
zero-bytes in their excess portion.
Harald.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
