Mailing list - Entries of 2006


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [qftestJUI] A possible race condition


  • Subject: RE: [qftestJUI] A possible race condition
  • From: "Kosmylev, Leonid" <Leonid.Kosmylev@?.com>
  • Date: Tue, 21 Mar 2006 14:54:07 +0100

Well, 

I confirmed that qftestJUI indeed "hides" an exception thrown by runnable: I
created a simple runnable that always throws a RuntimeException, and passed
it into SwingUtilities.invokeLater().
While the application itself reacts on the first occurance of the
RuntimeException by displaying an error message box, if the application is
executed under qftestJUI no error message box is displayed, the runnable is
invoked twice, and stack traces are the same as in our original problem.

But now our original problem disappeared as suddenly as it has appeared one
week ago (or maybe it is my debugging code at the end of that "thin wrapper"
affects execution so dramatically that the problem disappeared). I will
continue some experimets, but if the problem will not be reproduced I will
have to let it go.

As for version of qftestJUI: I was no involved in that originally, I am not
involved in this at the moment either - I am just investigating the problem
we have got. My quess would be: "if it ain't broken do not fix it".

Regards,

Leonid



-----Original Message-----
From: Gregor Schmid [mailto:Gregor.Schmid@?.de] 
Sent: Tuesday, March 21, 2006 14:39
To: Kosmylev, Leonid
Subject: Re: [qftestJUI] A possible race condition


Hi Leonid,

have you found anything yet?

Independent of that, I'd like to create a fix for the problem, but I cannot
create a patch against qftestJUI version 1.06.0 which is almost two years
out of date. Is there any reason why you're not using our latest and
greatest version 1.08.5?

Best regards,
    Greg

"Kosmylev, Leonid" <Leonid.Kosmylev@?.com> writes:

> Hi.
> 
> Actually our application is just a set of plugins to some other 
> application, and that one installs its EventQueue.
> 
> Now, I tried to do try/catch/finally around the runnable (I suspected 
> some kind of retry, but actually from the application itself, not from 
> qftestJUI), and our runnable DID not throw any exception. That is why 
> I suspected some race conditions.
> 
> But your answer got me thinking... Actually what happens is that there 
> is a thin wrapper around our quite complex runnable. I know for sure 
> our runnable does not throw any exceptions, but that thin wrapper is 
> another story. I did not checked it yet. It is the next thing I will try
to do next week.
> 
> Thanks for the answer.
> 
> Leonid
> 
> 
> 
> -----Original Message-----
> From: Gregor Schmid [mailto:Gregor.Schmid@?.de]
> Sent: Friday, March 17, 2006 15:51
> To: qftestJUI-list@?.de
> Cc: Kosmylev, Leonid
> Subject: Re: [qftestJUI] A possible race condition
> 
> 
> Hello Leonid,
> 
> interesting observation. Looks like your Runnable is throwing an 
> uncaught exception. ALso, your app appears to install its own EventQueue.
> 
> What happens is that qftest tries to dispatch the event through your 
> EventQueue and if that fails it dispatches the event itself. Looks 
> like qftest should put more effort in trying to detect where the 
> exception acually comes from. If the event was properly dispatched 
> through your queue but the EventListener (or the Runnable in this
> case) throws an exception, that exception should be passed on and the 
> Event not redispatched.
> 
> Can you confirm this theory by adding a try/catch to the respective 
> runnable?
> 
> Best regards,
>     Greg
> 
> "Kosmylev, Leonid" <Leonid.Kosmylev@?.com> writes:
> 
> > Hi,
> > 
> > We are using qftestJUI version 1.06.0 (build 919) to test our 
> > product, mostly on linux ("uname -r" reports 2.6.11-1.1369_FC4smp).
> > 
> > Recently we started to run into a very strange problem which was 
> > tracked to qftestJUI itself.
> > 
> > We have piece of code that looks like this:
> > 
> > Runnable  r = ...;
> > SwingUtilities.invokeLater(r);
> > 
> > Where the runnable is doing quite a lot, including but not limiting 
> > to swing calls. Sometimes (approx. 15%-20% of our test runs) the 
> > code in the runnable is invoked twice.
> > 
> > We put some debugging output (Thread.dumpStack()) in the runnable's
> > run() method.
> > 
> > Results:
> > Test runs where the runnable is invoked once have the following output:
> > 
> >         at <Our runnable's run() method> 
> >         at
> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
> >         at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
> >         at sun.reflect.GeneratedMethodAccessor38.invoke(Unknown Source)
> >         at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce
> > ss
> > orImpl
> > .java:25)
> >         at java.lang.reflect.Method.invoke(Method.java:324)
> >         at de.qfs.lib.util.Reflector.call(Reflector.java:112)
> >         at
> >
> de.qfs.apps.qftest.client.TestEventQueue.doDispatch(TestEventQueue.jav
> a:223)
> >         at de.qfs.lib.gui.EventQueue.dispatchEvent(EventQueue.java:569)
> >         at
> > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchT
> > hr
> > ead.ja
> > va:201)
> >         at
> > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThr
> > ea
> > d.java
> > :151)
> >         at
> > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
> >         at
> > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
> >         at
> > java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
> > 
> > 
> > Test runs where the runnable is invoked twice have the following output:
> > 1. First invocation (note that is it the same as the one above):
> > 
> >         at <Our runnable's run() method> 
> >         at
> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
> >         at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
> >         at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
> >         at
> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce
> > ss
> > orImpl
> > .java:25)
> >         at java.lang.reflect.Method.invoke(Method.java:324)
> >         at de.qfs.lib.util.Reflector.call(Reflector.java:112)
> >         at
> >
> de.qfs.apps.qftest.client.TestEventQueue.doDispatch(TestEventQueue.jav
> a:223)
> >         at de.qfs.lib.gui.EventQueue.dispatchEvent(EventQueue.java:569)
> >         at
> > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchT
> > hr
> > ead.ja
> > va:201)
> >         at
> > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThr
> > ea
> > d.java
> > :151)
> >         at
> > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
> >         at
> > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
> >         at
> > java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
> > 
> > 2. Second invocation:
> > 
> >         at <Our runnable's run() method> 
> >         at
> java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
> >         at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
> >         at de.qfs.lib.gui.EventQueue.doDispatch(EventQueue.java:656)
> >         at
> >
> de.qfs.apps.qftest.client.TestEventQueue.doDispatch(TestEventQueue.jav
> a:240)
> >         at de.qfs.lib.gui.EventQueue.dispatchEvent(EventQueue.java:569)
> >         at
> > java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchT
> > hr
> > ead.ja
> > va:201)
> >         at
> > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThr
> > ea
> > d.java
> > :151)
> >         at
> > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
> >         at
> > java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
> >         at
> > java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
> > 
> > Note that in the "normal" case the event is dispatched at line 
> > TestEventQueue.java:223, while the abnormal second case is coming 
> > from TestEventQueue.java:240
> > 
> > What is also strange that we use SwingUtilities.invokeLater in a lot 
> > of places but it looks like at the moment we have the problem with 
> > it only in one particular place.
> > 
> > Of course it is easy to work around this particular problem just by 
> > adding flag "alreadyExecuted" to the runnable, but what we do not 
> > want to do is to add such a flag to _each_ place where we use
> SwingUtilities.invokeLater().
> > 
> > Everything points to a potential race condition in class
> > TestEventQueue: for some reasons sometimes it "forgets" that an 
> > event was already processed (?)
> > 
> > Has anybody else seen such a problem? 
> > 
> > Regards,
> > 
> > Leonid Kosmylev
> > 
> 
> -- 
> Gregor Schmid                                Gregor.Schmid@?.de
> Quality First Software GmbH                     http://www.qfs.de
> Tulpenstr. 41                                Tel: +49 8171 919870
> DE-82538 Geretsried                          Fax: +49 8171 919876
> 
> 
> --
> The contents of this e-mail are intended for the named addressee only. 
> It contains information that may be confidential. Unless you are the 
> named addressee or an authorized designee, you may not copy or use it, 
> or disclose it to anyone else. If you received it in error please 
> notify us immediately and then destroy it.

-- 
Gregor Schmid                                Gregor.Schmid@?.de
Quality First Software GmbH                     http://www.qfs.de
Tulpenstr. 41                                Tel: +49 8171 919870
DE-82538 Geretsried                          Fax: +49 8171 919876


-- 
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it. 



Videos Downloads Documentation Buy Free Trial