DO NOT REPLY [Bug 45443] New: Deadlock using invokeAndWait from RunnableQueue

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=45443

           Summary: Deadlock using invokeAndWait from RunnableQueue
           Product: Batik
           Version: 1.6
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Utilities
        AssignedTo: batik-dev@xmlgraphics.apache.org
        ReportedBy: Alexander.Al-Bahrani@siemens.com


Created an attachment (id=22291)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=22291)
Bugfixed version of RunnableQueue

We use Batik for State Visualisation of System Components.
One possible State is "Emergency Stop" which results in Color = red and the
elements start flashing.

The UI is a Swing UI using the JSVGCanvas. Flashing is done by a
java.util.Timer changing visibility of DOM elements.
The Timer just runs one TimerTask using the "repeated fixed-delay execution"
mode.
See Javadoc of the following Timer method for more details:
public void schedule(TimerTask task,
                     Date firstTime,
                     long period)

Now we get this strange bahaviour that sometimes after loading a new
SVG-Document via JSVGCanvas.setURI() the flashing does not start anymore.
During further investigation we found out that the Timer just stoped working
because of a unreleased lock in org.apache.batik.util.LockableLink. The problem
is the implementation of the org.apache.batik.util.RunnableQueue.run() method.

In this special situation the runnable is doing its normal job. Element
changing colors, ... however. Now a setURI() call occurs and the RunnableQueue
is halted and ends its work, new document is loaded and new instance of
RunnableQueue takes over.

But what happens to the tasks laying on the "old" RunnableQueue?
The invokeLater()-runnables are no problem. Capsulated in a
org.apache.batik.util.Link class there is just no more reference and they just
disappear.
The invokeAndWait()-runnnables have a different behaviour. When they are pushed
to the RunnableQueue they set a lock causing the caller Thread to wait until
the runnable finished. But the runnable may have not even started execution, so
the lock will never be released and the caller Thread waits forever.

I think just a few lines of "cleanup" code added to RunnableQueue.run() will
solve the problem. I'll attach a bugfixed version of the class.
I've also taken a look in the batik1.7 implementation and the problem is
already not solved there.

I'll try to make a test implementation that reproduces the problem, but
currently I don't have one. Sorry.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org