[BATIK-840] Deadlock using invokeAndWait from RunnableQueue

• Type: Bug
• Status: Open
• Resolution: Unresolved
• Affects Version/s: 1.6
• Component/s: Utilities
• Environment: Operating System: Windows XP; Platform: PC
• Assignee: Batik Developer's Mailing list
• Reporter: Alexander Al-Bahrani
• Created: 21/Jul/08 01:59
• Updated: 21/Jul/08 01:59

Description

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.