Mailingliste - Einträge 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: Fri, 17 Mar 2006 19:49:51 +0100

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(DelegatingMethodAccess
> 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.java:223)
>         at de.qfs.lib.gui.EventQueue.dispatchEvent(EventQueue.java:569)
>         at
> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThr
> ead.ja
> va:201)
>         at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThrea
> 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(DelegatingMethodAccess
> 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.java:223)
>         at de.qfs.lib.gui.EventQueue.dispatchEvent(EventQueue.java:569)
>         at
> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThr
> ead.ja
> va:201)
>         at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThrea
> 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.java:240)
>         at de.qfs.lib.gui.EventQueue.dispatchEvent(EventQueue.java:569)
>         at
> java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThr
> ead.ja
> va:201)
>         at
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThrea
> 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. 



Videos Downloads Dokumentation Kaufen Gratis Testen