Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6814989

STPE terminates when policy set to continue executing existing periodic tasks

    XMLWordPrintable

Details

    • b93
    • 6
    • b02
    • generic, arm
    • generic, linux
    • Verified

    Backports

      Description

        This bug is for tracking purposes.

        jdk6 (and also updates to at least 6u14) allow a STPE to terminate where there is a periodic task and the policy is set to continue executing periodic tasks. This is demonstrated by the following test (which is based on http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/test/tck/ScheduledExecutorTest.java). The bug does not exist in jdk5 or jdk7 builds.

        import java.util.concurrent.*;

        public class Test {

           static final ThreadFactory daemonThreadFactory = new ThreadFactory() {
                @Override
                public Thread newThread(Runnable r) {
                    Thread t = new Thread(r);
                    t.setDaemon(true);
                    return t;
               }
            };

           static class NoOpRunnable implements Runnable {
               public void run() { }
           }

           public static void main(String[] args) throws Exception {
               ScheduledThreadPoolExecutor pool =
                   new ScheduledThreadPoolExecutor(1, daemonThreadFactory);
               pool.setContinueExistingPeriodicTasksAfterShutdownPolicy(true);
               pool.scheduleAtFixedRate(new NoOpRunnable(), 2, 2, TimeUnit.SECONDS);
               pool.shutdown();
               boolean terminated = pool.awaitTermination(10, TimeUnit.SECONDS);
               if (terminated)
                   throw new RuntimeException("terminated??");
           }
        }
        Recently we were running JCK on 6u14 b03 (64bit) on SLES11 x64 in a Virtual Box.
        It appears that
        api/java_util/concurrent/ScheduledExecutor/index.html#ScheduledExecutor
        api/java_util/concurrent/ScheduledExecutorSubclass/index.html#ScheduledExecutorSubclass
        JCK tests more fail than pass in such config.

        I was unsuccessfull with rerunning api/java_util/concurrent/ScheduledExecutor/index.html#ScheduledExecutor
        even with -platform.concurrentShortDelay 5000

        In such configuration failures are good reproducible since 1.6.0 fcs.
        Switching from Vortual Box to real machine greatly reduces failure rate.
        Failures were also more often on Ubuntu muchine in Virtual Box.
        Since this all configurations will be supported, I'm rising priority of the bug.

        To reproduce failures:
        1. Install SLES11 64bit in Virtual Box.
        2. Install 64bit jdk (for ex. to /export/jdk/jdk1.6.0_14)
        3. Install JCK6b (for ex. to /export/JCK/JCK-runtime-6b)
        4. Prepare a simple script to run a test:
        #!/bin/bash

        export JAVA=/export/jdk/jdk1.6.0_14/jre/bin/java
        export CLASSPATH="/export/JCK/JCK-runtime-6b/classes"

        OPTS=""
        TEST="javasoft.sqe.tests.api.java.util.concurrent.ScheduledExecutorTest"
        #TEST="javasoft.sqe.tests.api.java.util.concurrent.ScheduledExecutorSubclassTest"
        TOPTS="-platform.concurrentShortDelay 2000"

        $JAVA $OPTS -version
        $JAVA $OPTS $TEST $TOPTS

        Installed jck could be found at /java/re/jck/6b/promoted/latest/binaries/JCK-runtime-6b/
        Test sources is at /java/re/jck/6b/promoted/latest/binaries/JCK-runtime-6b/tests/
        Same situation with Xandros OS on Qualcomm device. See CR 6823412.

        Attachments

          Issue Links

            Activity

              People

                alanb Alan Bateman
                alanb Alan Bateman
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: