Chuck Williams wrote:
Hi All,
I found this issue. There is no problem in Lucene, and I'd like to
leave this thread with that assertion to avoid confusing future archive
searcher/readers.
The index was actually not corrupt at all. I use ParallelReader and
ParallelWriter. A kill -9 can leave t
Hi All,
I found this issue. There is no problem in Lucene, and I'd like to
leave this thread with that assertion to avoid confusing future archive
searcher/readers.
The index was actually not corrupt at all. I use ParallelReader and
ParallelWriter. A kill -9 can leave the subindexes out of syn
I do have one module that does custom index operations. This is my bulk
updater. It creates new index files for the segments it modifies and a
new segments file, then uses the same commit mechanism as merging.
I.e., it copes its new segments file into "segments" with the commit
lock only after a
I am not stating that you did not uncover a problem. I am only
stating that it is not due to OS level caching.
Maybe your sequence of events triggered a reread of the index, while
some thread was still writing. The reread sees the 'unused segments'
and deletes them, and then the other threa
robert engels wrote on 09/11/2006 07:34 AM:
> A kill -9 should not affect the OS's writing of dirty buffers
> (including directory modifications). If this were the case, massive
> system corruption would almost always occur every time a kill -9 was
> used with any program.
>
> The only thing a kill
A kill -9 should not affect the OS's writing of dirty buffers
(including directory modifications). If this were the case, massive
system corruption would almost always occur every time a kill -9 was
used with any program.
The only thing a kill -9 affects is user level buffering. The OS
al
On Monday 11 September 2006 15:36, Yonik Seeley wrote:
> On 9/10/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
> > Could a kill -9 prevent data from reaching disk for files that were
> > previously closed?
>
> No. After a close() the OS should have all the data... the process
> may be killed but
On Monday 11 September 2006 09:50, Chuck Williams wrote:
>
> Paul Elschot wrote on 09/10/2006 09:15 PM:
> > On Monday 11 September 2006 02:24, Chuck Williams wrote:
> >
> >> Hi All,
> >>
> >> An application of ours under development had a memory link that caused
> >> it to slow interminably. O
Yonik Seeley wrote:
On 9/11/06, Michael McCandless <[EMAIL PROTECTED]> wrote:
However, I do think it would be a good idea to [optionally] add a
sync() call on committing the segments file to still be robust to OS /
machine crashing... it would slow down performance of indexing but
hopefully not
On 9/11/06, Michael McCandless <[EMAIL PROTECTED]> wrote:
However, I do think it would be a good idea to [optionally] add a
sync() call on committing the segments file to still be robust to OS /
machine crashing... it would slow down performance of indexing but
hopefully not by too much since the
Yonik Seeley wrote:
On 9/10/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
Could a kill -9 prevent data from reaching disk for files that were
previously closed?
No. After a close() the OS should have all the data... the process
may be killed but the OS will eventually flush all the buffers, e
On 9/10/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
Could a kill -9 prevent data from reaching disk for files that were
previously closed?
No. After a close() the OS should have all the data... the process
may be killed but the OS will eventually flush all the buffers, etc.
File creation is
Paul Elschot wrote on 09/10/2006 09:15 PM:
> On Monday 11 September 2006 02:24, Chuck Williams wrote:
>
>> Hi All,
>>
>> An application of ours under development had a memory link that caused
>> it to slow interminably. On linux, the application did not response to
>> kill -15 in a reasonable
On Monday 11 September 2006 02:24, Chuck Williams wrote:
> Hi All,
>
> An application of ours under development had a memory link that caused
> it to slow interminably. On linux, the application did not response to
> kill -15 in a reasonable time, so kill -9 was used to forcibly terminate
> it.
Hi All,
An application of ours under development had a memory link that caused
it to slow interminably. On linux, the application did not response to
kill -15 in a reasonable time, so kill -9 was used to forcibly terminate
it. After this the segments file contained a reference to a segment
whose
15 matches
Mail list logo
