[
https://issues.apache.org/jira/browse/LUCENE-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918000#action_12918000
]
Michael McCandless commented on LUCENE-2688:
--------------------------------------------
I'm not talking about Android support -- that's a much larger (and
more challenging) question.
I'm talking about relying on as few dependencies (including java APIs)
as possible, to reduce the chance of problems. This philosophy
applies all across lucene sources, but especially to our very low
level APIs like locking.
So... is/was j.l.management really the only way to solve this problem?
Wouldn't seeding with System.nanoTime also suffice?
Hmm... maybe a better solution is to stop acquiring a test lock
altogether? Only NativeFSLockFactory does this..., and it's actually
rather silly, because we acquireTestLock when .makeLock is called,
yet, the caller who called .makeLock will presumably shortly
thereafter call .obtain on that lock and will at that point see an
exception if there are issues with native locks on the current
filesystem.
Note that we are only trying to generate a unique name for the *test*
lock that the lock factory acquires to verify locking will work. As
far as I know, no app has ever hard a problem with this, ie, this is a
test-only problem. In fact, even reading through LUCENE-2421 again, I
don't get why our tests are running simultaneous tests sharing the
same lock directory? Shai do you remember which specific tests cause
problems? And if the test lock was a problem, why then was the real
lock not a problem?
> NativeFSLockFactory throws an exception on Android 2.2 platform as
> java.lang.management package is not available on android.
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2688
> URL: https://issues.apache.org/jira/browse/LUCENE-2688
> Project: Lucene - Java
> Issue Type: Bug
> Components: Store
> Affects Versions: 3.0, 3.0.1, 3.0.2
> Environment: Android 2.2 Froyo Nexus One
> Reporter: Surinder Pal Singh Bindra
> Fix For: 2.9.4, 3.0.3, 3.1, 4.0
>
>
> NativeFSLockFactory throws an exception on Android 2.2 platform as
> java.lang.management package is not available on android.
> Looks like FSDirectory defaults to NativeFSLockFactory, and this class
> refers to java.lang.management package to generate a unique lock.
> java.lang.management is not available in Android 2.2 and hence a runtime
> exception is raised. The workaround is to use another custom LockFactory or
> SimpleFSLockFactory, but Fixing NativeFSLockFactroy will help.
> Thanks,
> Surinder
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
