JDK-7167780 : Hang javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 7a,7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-05-10
  • Updated: 2013-09-12
  • Resolved: 2012-08-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7u40Fixed 8 b51Fixed
Related Reports
Relates :  
Relates :  
From HP:

Hang is observed while running the jck test javasoft.sqe.tests.api.javax.swing.Timer.Ctor2Tests with JDK 7.0 on NonStop system which does not have Kernel level thread. This is not seen with JDK 6.0
On analysis of the issue, it was found that the run() method of the thread that posts the timer event in javax/swing/TimerQueue.java was in a continuous loop, thus not allowing the running of other threads.
This resulted in a hang on NonStop, since it does not have Kernel Level Thread.
On comparing javax/swing/TimerQueue.java of 7.0 with 6.0, it was observed that the file has changed significantly.
However it was observed that when the run() method is executed, the postExpiredTimers() method in it makes a call to wait with the following comment in 6.0 . Adding this in 7.0 solves the issue.
                // Allow other threads to call addTimer() and removeTimer()
                // even when we are posting Timers like mad.  Since the wait()
                // releases the lock, be sure not to maintain any state
                // between iterations of the loop.
                try {
                catch (InterruptedException e) {

When we put the following change  in 7.0 after the timer.isRepeats(), we observed that the testcase  is passing.
Thus the below code changes are required on platform not supporting Kernel Level Threads.
173:                       try {
174:                           DelayedTimer delayedTimer = timer.delayedTimer;
175:                           if (delayedTimer != null) {
176:                               /*
177:                                * Timer is not removed after we get it from
178:                                * the queue and before the lock on the timer is
179:                                * acquired
180:                                */
181:                               timer.post(); // have timer post an event
182:                               timer.delayedTimer = null;
183:                               if (timer.isRepeats()) {
184:                                   delayedTimer.setTime(now()
185:                                       + TimeUnit.MILLISECONDS.toNanos(
186:                                             timer.getDelay()));
187:                                   addTimer(delayedTimer);
188:                               }
189:                               try {
190:                                   wait(1);
191:                               } catch ( InterruptedException e ) {
192:                               }
189:                           }
190:                       } catch (SecurityException ignore) {
191:                       } finally {
192:                           timer.getLock().unlock();
193:                       }
194:                   } catch (InterruptedException ie) {
195:                       // Shouldn't ignore InterruptedExceptions here, so AppContext
196:                       // is disposed gracefully, see 6799345 for details
197:                       if (AppContext.getAppContext().isDisposed()) {
198:                           break;
199:                       }
200:                   }
As the above code breaks with system that does not have Kernel Threads ,   we would like Oracle to  address this issue. Also , as TimerQueue.java  has changed a lot we would like Oracle to review the suggested fix and provide your feedback.

using the JCK test

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/jdk/rev/3502753a9d66

EVALUATION We should pause Timer thread for a while to allow other threads to run.

EVALUATION The description of this CR does not have any questions of doubts about validity of the JCK test. For some reason it provides a suggestion on how to improve RI to make the test pass on HP system. This looks strange as nothing prevents HP to apply the suggested fix to their implementation. In any case this CR should be re-dispatched to the JDK side and I think in a form of an RFE.