Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Id
    • Labels:
      None

      Description

      I downloaded the HEAD of SVN, ran the tests and I get three failures (appended to end of message). Is there a more stable version that I can download/build?

      org.apache.commons.id.uuid.state.NodeTest
      testNodebyteArray(org.apache.commons.id.uuid.state.NodeTest)
      java.lang.IllegalThreadStateException
      at java.lang.Thread.start(Thread.java:571)
      at org.apache.commons.id.uuid.clock.ThreadClockImpl.getUUIDTime(ThreadClockImpl.java:174)
      at org.apache.commons.id.uuid.state.Node.getUUIDTime(Node.java:116)
      at org.apache.commons.id.uuid.state.NodeTest.testNodebyteArray(NodeTest.java:63)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:585)
      at junit.framework.TestCase.runTest(TestCase.java:154)
      at junit.framework.TestCase.runBare(TestCase.java:127)
      at junit.framework.TestResult$1.protect(TestResult.java:106)
      at junit.framework.TestResult.runProtected(TestResult.java:124)
      at junit.framework.TestResult.run(TestResult.java:109)
      at junit.framework.TestCase.run(TestCase.java:118)
      at junit.framework.TestSuite.runTest(TestSuite.java:208)
      at junit.framework.TestSuite.run(TestSuite.java:203)
      at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
      at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

      testGetUUIDTime(org.apache.commons.id.uuid.state.NodeTest)
      java.lang.IllegalThreadStateException
      at java.lang.Thread.start(Thread.java:571)
      at org.apache.commons.id.uuid.clock.ThreadClockImpl.getUUIDTime(ThreadClockImpl.java:174)
      at org.apache.commons.id.uuid.state.Node.getUUIDTime(Node.java:116)
      at org.apache.commons.id.uuid.state.NodeTest.testGetUUIDTime(NodeTest.java:104)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:585)
      at junit.framework.TestCase.runTest(TestCase.java:154)
      at junit.framework.TestCase.runBare(TestCase.java:127)
      at junit.framework.TestResult$1.protect(TestResult.java:106)
      at junit.framework.TestResult.runProtected(TestResult.java:124)
      at junit.framework.TestResult.run(TestResult.java:109)
      at junit.framework.TestCase.run(TestCase.java:118)
      at junit.framework.TestSuite.runTest(TestSuite.java:208)
      at junit.framework.TestSuite.run(TestSuite.java:203)
      at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
      at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

      testGetLastTimestamp(org.apache.commons.id.uuid.state.NodeTest)
      java.lang.IllegalThreadStateException
      at java.lang.Thread.start(Thread.java:571)
      at org.apache.commons.id.uuid.clock.ThreadClockImpl.getUUIDTime(ThreadClockImpl.java:174)
      at org.apache.commons.id.uuid.state.Node.getUUIDTime(Node.java:116)
      at org.apache.commons.id.uuid.state.NodeTest.testGetLastTimestamp(NodeTest.java:129)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:585)
      at junit.framework.TestCase.runTest(TestCase.java:154)
      at junit.framework.TestCase.runBare(TestCase.java:127)
      at junit.framework.TestResult$1.protect(TestResult.java:106)
      at junit.framework.TestResult.runProtected(TestResult.java:124)
      at junit.framework.TestResult.run(TestResult.java:109)
      at junit.framework.TestCase.run(TestCase.java:118)
      at junit.framework.TestSuite.runTest(TestSuite.java:208)
      at junit.framework.TestSuite.run(TestSuite.java:203)
      at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
      at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
      at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

      1. ThreadClockImpl_jdk6.patch
        2 kB
        Martin Kalén
      2. ThreadClockImpl.patch
        2 kB
        Martin Kalén

        Activity

        Hide
        Joerg Schaible added a comment -

        No, these are not known. However, as long as you do not specify your environment, nothing will happen either.

        Show
        Joerg Schaible added a comment - No, these are not known. However, as long as you do not specify your environment, nothing will happen either.
        Hide
        Martin Kalén added a comment -

        I have been able to reproduce this by running "mvn package" from Commons Id updated from SVN at 2008-07-23T09:00 UTC.

        I suspect that it could be JDK6-related.

        My environment is as follows:

        Maven: Maven version: 2.0.9
        
        O/S: Ubuntu 8.04.1
        Linux 2.6.24-19-generic #1 SMP i686 GNU/Linux
        
        JRE: Sun JDK 6.0u6
        java version "1.6.0_06"
        Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
        Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing)
        

        Same exceptions but for the JDK source itself.

        NodeTest#testNodebyteArray
        java.lang.IllegalThreadStateException
        at java.lang.Thread.start(Thread.java:595)
        at org.apache.commons.id.uuid.clock.ThreadClockImpl.getUUIDTime(ThreadClockImpl.java:174)
        at org.apache.commons.id.uuid.state.Node.getUUIDTime(Node.java:116)
        at org.apache.commons.id.uuid.state.NodeTest.testNodebyteArray(NodeTest.java:63)
        
        NodeTest#testGetUUIDTime
        java.lang.IllegalThreadStateException
        at java.lang.Thread.start(Thread.java:595)
        at org.apache.commons.id.uuid.clock.ThreadClockImpl.getUUIDTime(ThreadClockImpl.java:174)
        at org.apache.commons.id.uuid.state.Node.getUUIDTime(Node.java:116)
        at org.apache.commons.id.uuid.state.NodeTest.testGetUUIDTime(NodeTest.java:104)
        
        NodeTest#testGetLastTimestamp
        java.lang.IllegalThreadStateException
        at java.lang.Thread.start(Thread.java:595)
        at org.apache.commons.id.uuid.clock.ThreadClockImpl.getUUIDTime(ThreadClockImpl.java:174)
        at org.apache.commons.id.uuid.state.Node.getUUIDTime(Node.java:116)
        at org.apache.commons.id.uuid.state.NodeTest.testGetLastTimestamp(NodeTest.java:129)
        
        Show
        Martin Kalén added a comment - I have been able to reproduce this by running "mvn package" from Commons Id updated from SVN at 2008-07-23T09:00 UTC. I suspect that it could be JDK6-related. My environment is as follows: Maven: Maven version: 2.0.9 O/S: Ubuntu 8.04.1 Linux 2.6.24-19-generic #1 SMP i686 GNU/Linux JRE: Sun JDK 6.0u6 java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode, sharing) Same exceptions but for the JDK source itself. NodeTest#testNodebyteArray java.lang.IllegalThreadStateException at java.lang. Thread .start( Thread .java:595) at org.apache.commons.id.uuid.clock.ThreadClockImpl.getUUIDTime(ThreadClockImpl.java:174) at org.apache.commons.id.uuid.state.Node.getUUIDTime(Node.java:116) at org.apache.commons.id.uuid.state.NodeTest.testNodebyteArray(NodeTest.java:63) NodeTest#testGetUUIDTime java.lang.IllegalThreadStateException at java.lang. Thread .start( Thread .java:595) at org.apache.commons.id.uuid.clock.ThreadClockImpl.getUUIDTime(ThreadClockImpl.java:174) at org.apache.commons.id.uuid.state.Node.getUUIDTime(Node.java:116) at org.apache.commons.id.uuid.state.NodeTest.testGetUUIDTime(NodeTest.java:104) NodeTest#testGetLastTimestamp java.lang.IllegalThreadStateException at java.lang. Thread .start( Thread .java:595) at org.apache.commons.id.uuid.clock.ThreadClockImpl.getUUIDTime(ThreadClockImpl.java:174) at org.apache.commons.id.uuid.state.Node.getUUIDTime(Node.java:116) at org.apache.commons.id.uuid.state.NodeTest.testGetLastTimestamp(NodeTest.java:129)
        Hide
        Martin Kalén added a comment -

        Suggestion/draft patch that makes Commons Id's ThreadClockImpl class JDK6-compliant. Follows the guidelines outlined in Sun's technote about changes in the Thread class. Backwards compatible; tested with Sun JDK6 (6.0u6), JDK5 (5.0u15) and JDK1.4 (1.4.2u15) on Ubuntu Linux. Feel free to modify as you see fit, but at least this should be a starting point for JDK6-compliance.

        Show
        Martin Kalén added a comment - Suggestion/draft patch that makes Commons Id's ThreadClockImpl class JDK6-compliant. Follows the guidelines outlined in Sun's technote about changes in the Thread class. Backwards compatible; tested with Sun JDK6 (6.0u6), JDK5 (5.0u15) and JDK1.4 (1.4.2u15) on Ubuntu Linux. Feel free to modify as you see fit, but at least this should be a starting point for JDK6-compliance.
        Hide
        Donal Murtagh added a comment -

        Actually, I experienced the problem on JDK 5

        Show
        Donal Murtagh added a comment - Actually, I experienced the problem on JDK 5
        Hide
        Sebb added a comment -

        In the patch dated 2008-07-23 02:26 AM, the workerSuspended boolean needs to be made volatile, as the accesses are from different threads.

        Also, surely the currentTimeMillis field should be protected using the same synchronize target each time ?
        At present the new code uses SystemClockImpl.class and the original uses ThreadClockImpl.class.

        Also the wait is on the run() instance, whereas the notify is applied to a potentially different instance.
        The quoted Sun artice recommends using Thread.interrupt() - it's not clear why wait/notify are used instead.

        Show
        Sebb added a comment - In the patch dated 2008-07-23 02:26 AM, the workerSuspended boolean needs to be made volatile, as the accesses are from different threads. Also, surely the currentTimeMillis field should be protected using the same synchronize target each time ? At present the new code uses SystemClockImpl.class and the original uses ThreadClockImpl.class. Also the wait is on the run() instance, whereas the notify is applied to a potentially different instance. The quoted Sun artice recommends using Thread.interrupt() - it's not clear why wait/notify are used instead.
        Hide
        Joerg Schaible added a comment -

        Good catch, Sebb. The question is whether the problem still arises if in the original code the same synchronization target is used. Can anybody of the reporters simply try to exchange the SystemClockImpl.class to ThreadClockImpl.class in the getUUIDTime method and look if the problem persists?

        Show
        Joerg Schaible added a comment - Good catch, Sebb. The question is whether the problem still arises if in the original code the same synchronization target is used. Can anybody of the reporters simply try to exchange the SystemClockImpl.class to ThreadClockImpl.class in the getUUIDTime method and look if the problem persists?
        Hide
        Martin Kalén added a comment -

        Thank you for your feedback.

        The synchronization target used for the currentTimeMillis field indeed looks like a bug in the original code. Changing this to ThreadClockImpl.class in the getUUIDTime does however not change the fact that Thread.start() can no longer be performed on a thread where the run() method has already completed (same IllegalStateExceptions, see the technote and recent JavaDoc for more information).

        I agree with Sebb that the workerSuspended needs to be made volatile and will attach a new patch without this flaw.

        However, I do not (yet?) see why the pattern from the technote using wait+notify as a substitution for suspend+resume (or like the original code: complete/end+re-start) is wrong. wait() and notify() both work on the Object's monitor and are, as far as I understand, intended for cross-thread communication on instances rather than explicit threads.

        The way I read the technote Thread.interrupt() is recommended as a substitute for Thread.stop on a thread that waits for long periods ("e.g., for input"). I also read the original code as more of suspend/resume than explicit stop/start. The start() call seemed to me as just a substitute for re-run/resume, therefore I tried to follow the recommended patter for suspend/resume.

        All feedback and/or corrections are welcome.

        Show
        Martin Kalén added a comment - Thank you for your feedback. The synchronization target used for the currentTimeMillis field indeed looks like a bug in the original code. Changing this to ThreadClockImpl.class in the getUUIDTime does however not change the fact that Thread.start() can no longer be performed on a thread where the run() method has already completed (same IllegalStateExceptions, see the technote and recent JavaDoc for more information). I agree with Sebb that the workerSuspended needs to be made volatile and will attach a new patch without this flaw. However, I do not (yet?) see why the pattern from the technote using wait+notify as a substitution for suspend+resume (or like the original code: complete/end+re-start) is wrong. wait() and notify() both work on the Object's monitor and are, as far as I understand, intended for cross-thread communication on instances rather than explicit threads. The way I read the technote Thread.interrupt() is recommended as a substitute for Thread.stop on a thread that waits for long periods ("e.g., for input"). I also read the original code as more of suspend/resume than explicit stop/start. The start() call seemed to me as just a substitute for re-run/resume, therefore I tried to follow the recommended patter for suspend/resume. All feedback and/or corrections are welcome.
        Hide
        Martin Kalén added a comment -

        New patch with corrections after feedback from Sebb:

        • fix currentTimeMillis synchronization target in original code
        • use volatile field modifier for synchronization of concurrent read/write of the workerSuspended field between different threads
        Show
        Martin Kalén added a comment - New patch with corrections after feedback from Sebb: fix currentTimeMillis synchronization target in original code use volatile field modifier for synchronization of concurrent read/write of the workerSuspended field between different threads
        Hide
        Joerg Schaible added a comment -

        wait/notify is perfect for thread synchronization. Thread.interrupt() does have some other unwanted side-effects, because it does also interrupt I/O operations on some platforms (at least on Solaris).

        Show
        Joerg Schaible added a comment - wait/notify is perfect for thread synchronization. Thread.interrupt() does have some other unwanted side-effects, because it does also interrupt I/O operations on some platforms (at least on Solaris).

          People

          • Assignee:
            Unassigned
            Reporter:
            Donal Murtagh
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development