Jason Polites wrote:
It was definately NTFS, unfortunately it was a while ago, and most of the
code has changed.
Basically I had a multi-threaded app where multiple threads were writing to
the index (but exclusively... that is, I had my own locking mechanism
preventing concurrent writes).
In a
It was definately NTFS, unfortunately it was a while ago, and most of the
code has changed.
Basically I had a multi-threaded app where multiple threads were writing to
the index (but exclusively... that is, I had my own locking mechanism
preventing concurrent writes).
In a separate JVM, I had a
Jason Polites wrote:
Yeah.. I had a think about this, and I now remember why I originally
came to
the conclusion about cross-JVM access.
When I was adding documents to the index, and searching at the same time
(from a different JVM) I would get the occassional (but regular)
FileNotFoundExceptio
Yeah.. I had a think about this, and I now remember why I originally came to
the conclusion about cross-JVM access.
When I was adding documents to the index, and searching at the same time
(from a different JVM) I would get the occassional (but regular)
FileNotFoundException.
I don't recall the
: I had just assumed (foolishly) that cross-JVM access would be problematic.
nope .. the whole point of the lockfiles is to deal with multiple JVMs ...
otherwise Lucene locking could be accomplished entirely with
synchronization.
-Hoss
Wow. That's awesome.
I had just assumed (foolishly) that cross-JVM access would be problematic.
Maybe I should read the manual ;)
Cross machine access could be solved with some RMI magic.. but
performance/scalability may be an issue.
On 8/28/06, Michael McCandless <[EMAIL PROTECTED]> wrote:
Doron Cohen wrote:
"Jason Polites" <[EMAIL PROTECTED]> wrote on 27/08/2006 09:36:07:
I would have thought that simultaneous cross-JVM access to an index was
outside of scope of the core Lucene API (although it would be great), but
maybe the file system basis allows for this (?).
Lucene does p
Yonik Seeley wrote:
On 8/27/06, Doron Cohen <[EMAIL PROTECTED]> wrote:
I plan to submit an update to that patch later today accommodating your
comments (and others); It will most probably retry for IOExceptions (not
analyzing the exception text); also, it would return false if the *retry*
for ob
On 8/27/06, Doron Cohen <[EMAIL PROTECTED]> wrote:
I plan to submit an update to that patch later today accommodating your
comments (and others); It will most probably retry for IOExceptions (not
analyzing the exception text); also, it would return false if the *retry*
for obtain() failed with ex
"Jason Polites" <[EMAIL PROTECTED]> wrote on 27/08/2006 09:36:07:
> I would have thought that simultaneous cross-JVM access to an index was
> outside of scope of the core Lucene API (although it would be great), but
> maybe the file system basis allows for this (?).
Lucene does protect you from m
I would have thought that simultaneous cross-JVM access to an index was
outside of scope of the core Lucene API (although it would be great), but
maybe the file system basis allows for this (?).
I like the idea of catching IOExceptions and returning false. Conceptually,
failing to obtain a lock
On 8/26/06, Jason Polites <[EMAIL PROTECTED]> wrote:
Synchronization at this low level would ensure that outer application layers
would be guaranteed of IO isolation.
That still wouldn't solve two JVMs (or even two webapps) trying to
grab the same lock and getting an exception, correct?
It see
Jason Polites wrote:
Are you also running searchers against this index? Are they re-init'ing
frequently or being opened and then held open?
No searches running in my initial test, although I can't be certain what is
happening under the Compass hood.
OK.
This looks similar to http://issue
On 8/26/06, Michael McCandless <[EMAIL PROTECTED]> wrote:
Are you also running searchers against this index? Are they re-init'ing
frequently or being opened and then held open?
No searches running in my initial test, although I can't be certain what is
happening under the Compass hood.
This
Jason Polites wrote:
Hi all,
When indexing with multiple threads, and under heavy load, I get the
following exception:
java.io.IOException: Access is denied
at java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:850)
at org.apache.lucene
Hi all,
When indexing with multiple threads, and under heavy load, I get the
following exception:
java.io.IOException: Access is denied
at java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:850)
at org.apache.lucene.store.FSDirectory$1.o
16 matches
Mail list logo
