BTW if you have the CheckIndex output when you ran it on the two
failed indices, can you forward that?
Mike
On Thu, Jul 29, 2010 at 6:32 AM, Michael McCandless
wrote:
> On Wed, Jul 28, 2010 at 1:08 AM, David Sitsky wrote:
>> Incidentally.. this is what TerminateProcess does say from MSDN:
>>
>>
On Wed, Jul 28, 2010 at 1:08 AM, David Sitsky wrote:
> Incidentally.. this is what TerminateProcess does say from MSDN:
>
> TerminateProcess initiates termination and returns immediately. This
> stops execution of all threads within the process and requests
> cancellation of all pending I/O. The t
Incidentally.. this is what TerminateProcess does say from MSDN:
TerminateProcess initiates termination and returns immediately. This
stops execution of all threads within the process and requests
cancellation of all pending I/O. The terminated process cannot exit
until all pending I/O has been co
Hi Mike,
Definitely no OOME (or other critical errors), and if there were, we
would have terminated the program straight away.
Cheers,
David
On 28 July 2010 01:44, Michael McCandless wrote:
> Were there any exceptions during indexing, before the
> TerminateProcess() call? EG OOME?
>
> Mike
>
>
Were there any exceptions during indexing, before the
TerminateProcess() call? EG OOME?
Mike
On Tue, Jul 27, 2010 at 8:43 AM, Michael McCandless
wrote:
> On Mon, Jul 26, 2010 at 7:10 PM, David Sitsky wrote:
>> During processing.. there might be a number of reasons why we need to
>> shutdown th
On Mon, Jul 26, 2010 at 7:10 PM, David Sitsky wrote:
> During processing.. there might be a number of reasons why we need to
> shutdown the indexing process, but perhaps what is unusual is we call
> the win32 API TerminateProcess() call rather than System.exit(), for
> slightly obscure reasons. W
During processing.. there might be a number of reasons why we need to
shutdown the indexing process, but perhaps what is unusual is we call
the win32 API TerminateProcess() call rather than System.exit(), for
slightly obscure reasons. When calling exit(), this still calls a
large body of code (for
It's great that CheckIndex resolved it, but I'd like to get to the
root cause if possible.
Can you describe how the previous indexing process abnormally
terminated? Did the JRE crash/get killed? Did the OS/machine crash /
lose power?
Abnormal termination of any kind, background merges running o
Running CheckIndex -fix fixed both indexes which is a relief. In both
cases, it said 1 broken segment containing 1 document detected.
So any ideas on what might have caused this in the first place?
On 26 July 2010 16:58, David Sitsky wrote:
> As another data point, this happened on another inde
As another data point, this happened on another index:
java.io.IOException: background merge hit exception: _17a:C1003710
_18h:C66391 _1ct:C45384 _1wt:C104479 _1zo:C23469 _271:C58570
_2dk:C53760 _2h5:C109879 _2ik:C7713 _2ii:C121 _2ij:C243 _2il:C124
_2im:C122 _2in:C115 _2io:C138 _2ip:C131 _2iq:C116
Correction - this was with Lucene 2.9.3.
On 26 July 2010 14:21, David Sitsky wrote:
> Hi,
>
> A customer has been indexing a very large collection of documents that
> has been running over many days using 2.9.0. During the optimisation
> stage, the following error occurred, and now the index can
Hi,
A customer has been indexing a very large collection of documents that
has been running over many days using 2.9.0. During the optimisation
stage, the following error occurred, and now the index can no longer
be opened due to the "missing file". I have been told this index is
on a local RAID
12 matches
Mail list logo
