jira at apache
Nov 22, 2009, 2:36 AM
Post #3 of 5
(317 views)
Permalink
|
|
[jira] Commented: (LUCENE-1877) Use NativeFSLockFactory as default for new API (direct ctors & FSDir.open)
[In reply to]
|
|
[ https://issues.apache.org/jira/browse/LUCENE-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781111#action_12781111 ]
Thomas Mueller commented on LUCENE-1877:
----------------------------------------
> take it somewhere other than this closed issue.
Yes, where?
> shouldn't active code like that live in the application layer?
Why?
> exceed the polling interval for a low priority process on a system under heavy load?
The watchdog thread runs with high priority (see the H2 docs). It's still possible the thread isn't run at all, but highly unlikely. High priority threads are quite reliable. I wrote a MP3 player in Java (mp3transform) which I used a lot, I never heard any gaps. If the thread can be avoided, that would be great of course. I'm just trying to say that in theory, the thread is problematic, but in practice it isn't. While file locking is not a problem in theory, but in practice.
> What happens when the app sleeps?
Good question! Standby / hibernate are not supported. I didn't think about that. Is there a way to detect the wakeup?
> host name and the pid
Yes. It is not so easy to get the PID in Java, I found: http://stackoverflow.com/questions/35842/process-id-in-java "ManagementFactory.getRuntimeMXBean().getName()". What do you do if the lock was generated by another machine? I tried with using a server socket, so you need the IP address, but unfortunately, sometimes the network is not configured correctly (but maybe it's possible to detect that). Maybe the two machines can't access each other over TCP/IP.
> hard links
Yes, but it looks like this doesn't work always.
> Use NativeFSLockFactory as default for new API (direct ctors & FSDir.open)
> --------------------------------------------------------------------------
>
> Key: LUCENE-1877
> URL: https://issues.apache.org/jira/browse/LUCENE-1877
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Javadocs
> Reporter: Mark Miller
> Assignee: Uwe Schindler
> Fix For: 2.9
>
> Attachments: LUCENE-1877.patch, LUCENE-1877.patch, LUCENE-1877.patch, LUCENE-1877.patch
>
>
> A user requested we add a note in IndexWriter alerting the availability of NativeFSLockFactory (allowing you to avoid retaining locks on abnormal jvm exit). Seems reasonable to me - we want users to be able to easily stumble upon this class. The below code looks like a good spot to add a note - could also improve whats there a bit - opening an IndexWriter does not necessarily create a lock file - that would depend on the LockFactory used.
> {code} <p>Opening an <code>IndexWriter</code> creates a lock file for the directory in use. Trying to open
> another <code>IndexWriter</code> on the same directory will lead to a
> {@link LockObtainFailedException}. The {@link LockObtainFailedException}
> is also thrown if an IndexReader on the same directory is used to delete documents
> from the index.</p>{code}
> Anyone remember why NativeFSLockFactory is not the default over SimpleFSLockFactory?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe [at] lucene
For additional commands, e-mail: java-dev-help [at] lucene
|
