Lucene - Core
  1. Lucene - Core
  2. LUCENE-2688

NativeFSLockFactory throws an exception on Android 2.2 platform as java.lang.management package is not available on android.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0, 3.0.1, 3.0.2
    • Fix Version/s: 2.9.4, 3.0.3, 3.1, 4.0-ALPHA
    • Component/s: core/store
    • Labels:
      None
    • Environment:

      Android 2.2 Froyo Nexus One

    • Lucene Fields:
      New

      Description

      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

        Issue Links

          Activity

          Hide
          Michael McCandless added a comment -

          I agree we should fix this. We want portability. This is only used to try to create a unique lock name...

          Can we somehow load this dynamically? Such that on JVMs that do not have it, we fallback?

          Show
          Michael McCandless added a comment - I agree we should fix this. We want portability. This is only used to try to create a unique lock name... Can we somehow load this dynamically? Such that on JVMs that do not have it, we fallback?
          Hide
          Robert Muir added a comment -

          I don't think this is a bug.

          We are talking about android... its not actually Java...

          Show
          Robert Muir added a comment - I don't think this is a bug. We are talking about android... its not actually Java...
          Hide
          Shai Erera added a comment -

          Isn't it part of Java 5? Is Android using a different JDK? I agree w/ Robert on one hand, but adding a try-catch and fallback seems reasonable in this case.

          I'd only like to understand how is it that java.lang.management does not exist on Android, because that might indicate other classes don't exist as well, and thus fixing NativeFSLockFactory won't solve the real problem of running Lucene 3.x on Android.

          Show
          Shai Erera added a comment - Isn't it part of Java 5? Is Android using a different JDK? I agree w/ Robert on one hand, but adding a try-catch and fallback seems reasonable in this case. I'd only like to understand how is it that java.lang.management does not exist on Android, because that might indicate other classes don't exist as well, and thus fixing NativeFSLockFactory won't solve the real problem of running Lucene 3.x on Android.
          Hide
          Robert Muir added a comment -

          I'd only like to understand how is it that java.lang.management does not exist on Android, because that might indicate other classes don't exist as well, and thus fixing NativeFSLockFactory won't solve the real problem of running Lucene 3.x on Android.

          exactly my point!

          android doesn't have all the java apis (only a subset: http://developer.android.com/reference/packages.html)
          its not actually java...

          either we want lucene to fully work on it (which means we intentionally limit ourselves to the intersection of the
          java apis and the android apis, install a simulator on hudson, ensure ant test passes, etc), or we don't.

          but i don't think we should degrade anything for it, in other words we shouldn't limit ourselves to its subset
          if the damn thing isn't going to work anyway.

          Show
          Robert Muir added a comment - I'd only like to understand how is it that java.lang.management does not exist on Android, because that might indicate other classes don't exist as well, and thus fixing NativeFSLockFactory won't solve the real problem of running Lucene 3.x on Android. exactly my point! android doesn't have all the java apis (only a subset: http://developer.android.com/reference/packages.html ) its not actually java... either we want lucene to fully work on it (which means we intentionally limit ourselves to the intersection of the java apis and the android apis, install a simulator on hudson, ensure ant test passes, etc), or we don't. but i don't think we should degrade anything for it, in other words we shouldn't limit ourselves to its subset if the damn thing isn't going to work anyway.
          Hide
          Michael McCandless added a comment -

          I don't think this is a bug.

          We are talking about android... its not actually Java...

          I agree!

          This is not a bug, and we do not support Android (there
          are many things besides this usage of j.l.management that cause
          problems for Lucene on Android, right?).

          But, separately, I think when possible Lucene should use simpler code,
          fewer APIs, etc., to minimize the risk of problems.

          This usage of j.l.management seems frivolous? Can't we simply do a
          better job seeding Random (eg with System.nanoTime()), instead?

          Or, make the usage of j.l.management dynamic?

          Note that this was added for LUCENE-2421, which was only to make
          sure our tests don't make conflicting locks. It seems very unlikely
          a "real" app would hit this (the lock files live in the index dir). Maybe
          we can fix it for tests only (eg swap in different impl when tests are
          running...)?

          Show
          Michael McCandless added a comment - I don't think this is a bug. We are talking about android... its not actually Java... I agree! This is not a bug, and we do not support Android (there are many things besides this usage of j.l.management that cause problems for Lucene on Android, right?). But, separately, I think when possible Lucene should use simpler code, fewer APIs, etc., to minimize the risk of problems. This usage of j.l.management seems frivolous? Can't we simply do a better job seeding Random (eg with System.nanoTime()), instead? Or, make the usage of j.l.management dynamic? Note that this was added for LUCENE-2421 , which was only to make sure our tests don't make conflicting locks. It seems very unlikely a "real" app would hit this (the lock files live in the index dir). Maybe we can fix it for tests only (eg swap in different impl when tests are running...)?
          Hide
          Robert Muir added a comment -

          Maybe we can fix it for tests only (eg swap in different impl when tests are running...)?

          I think the actual tests should use our real code, as for LuceneJUnitResultFormatter, yes, i think you are right.

          Show
          Robert Muir added a comment - Maybe we can fix it for tests only (eg swap in different impl when tests are running...)? I think the actual tests should use our real code, as for LuceneJUnitResultFormatter, yes, i think you are right.
          Hide
          Shai Erera added a comment - - edited

          I don't understand why does an Android app need to lock the index at all, and even if – can't SimpleFS work?

          java.lang.management is perfectly legit, and is not an external dependency or anything. Luckily Android includes java.util.concurrent – what if it didn't? Would we attempt to fix Lucene too (IndexReader wouldn't work, for example).

          I personally don't mind if we fix it though, to use nanoTime() or wrap with try-catch and fallback to using nanoTime() there.

          It's just a question of what do we want to say about Android support.

          Show
          Shai Erera added a comment - - edited I don't understand why does an Android app need to lock the index at all, and even if – can't SimpleFS work? java.lang.management is perfectly legit, and is not an external dependency or anything. Luckily Android includes java.util.concurrent – what if it didn't? Would we attempt to fix Lucene too (IndexReader wouldn't work, for example). I personally don't mind if we fix it though, to use nanoTime() or wrap with try-catch and fallback to using nanoTime() there. It's just a question of what do we want to say about Android support.
          Hide
          Uwe Schindler added a comment -

          +1, it's java.lang.management, which is even in the basic "lang" package. If Android does not have it, its a killer. On android, you can work around with SimpleFSLock. If we start to supply workarounds, we will get into a hell of supporting abstruse environments.

          Show
          Uwe Schindler added a comment - +1, it's java.lang .management, which is even in the basic "lang" package. If Android does not have it, its a killer. On android, you can work around with SimpleFSLock. If we start to supply workarounds, we will get into a hell of supporting abstruse environments.
          Hide
          Robert Muir added a comment -

          Luckily Android includes java.util.concurrent - what if it didn't? Would we attempt to fix Lucene too (IndexReader wouldn't work, for example).

          I think it goes much deeper than this, besides having the APIs, do they actually work ?

          For example, with apache harmony (android uses its classlib!)
          there was/is some work to actually make tests pass: HARMONY-6640, HARMONY-6648, HARMONY-6649, HARMONY-6650

          fortunately the harmony developers were very helpful in getting things moving,
          but my point is that unless the tests pass, its pointless to waste time looking at the APIs

          Show
          Robert Muir added a comment - Luckily Android includes java.util.concurrent - what if it didn't? Would we attempt to fix Lucene too (IndexReader wouldn't work, for example). I think it goes much deeper than this, besides having the APIs, do they actually work ? For example, with apache harmony (android uses its classlib!) there was/is some work to actually make tests pass: HARMONY-6640 , HARMONY-6648 , HARMONY-6649 , HARMONY-6650 fortunately the harmony developers were very helpful in getting things moving, but my point is that unless the tests pass, its pointless to waste time looking at the APIs
          Hide
          Michael McCandless added a comment -

          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?

          Show
          Michael McCandless added a comment - 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?
          Hide
          Michael McCandless added a comment -

          This issue was fixed, as a side effect of fixing LUCENE-2689, which removed the acquireTestLock method (the only thing using j.l.management.*) entirely.

          Show
          Michael McCandless added a comment - This issue was fixed, as a side effect of fixing LUCENE-2689 , which removed the acquireTestLock method (the only thing using j.l.management.*) entirely.

            People

            • Assignee:
              Unassigned
              Reporter:
              Surinder Pal Singh Bindra
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development