Multiple applets in one page

Hi,

One of our customers has noticed the following issue: if you have separate applets in one html page, then the clipboard communication can run into an error, and the problem can only be solved with the restarting of the applet.

This issue is based on the fact that the applets are sharing the classloader, and some static references can be ruined.

The following stack trace on the java console when the clipboard is being disabled due to this problem:

Exception in thread "pool-4-thread-1" java.lang.IllegalMonitorStateException
    at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown Source)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown Source)
    at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
    at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
Exception in thread "AWT-EventQueue-3" java.lang.IllegalThreadStateException
    at java.lang.ThreadGroup.addUnstarted(Unknown Source)
    at java.lang.Thread.init(Unknown Source)
    at java.lang.Thread.<init>(Unknown Source)
    at java.util.concurrent.Executors$DefaultThreadFactory.newThread(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.addThread(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.execute(Unknown Source)
    at java.util.concurrent.AbstractExecutorService.submit(Unknown Source)
    at java.util.concurrent.Executors$DelegatedExecutorService.submit(Unknown Source)
    at chemaxon.marvin.modules.datatransfer.ClipboardHandler.c(Unknown Source)
    at chemaxon.marvin.modules.datatransfer.ClipboardHandler.putMoleculeToClipboard(Unknown Source)
    at chemaxon.marvin.common.swing.MolPanel.setMClipboardMol(Unknown Source)
    at chemaxon.marvin.view.swing.ViewPanel.a(Unknown Source)
    at chemaxon.marvin.view.swing.ViewPanel.doCopy(Unknown Source)
    at chemaxon.marvin.swing.action.CopyAction.doAction(Unknown Source)
    at chemaxon.marvin.swing.MAction.actionPerformed(Unknown Source)
    at javax.swing.SwingUtilities.notifyAction(Unknown Source)
    at javax.swing.JComponent.processKeyBinding(Unknown Source)
    at javax.swing.JComponent.processKeyBindings(Unknown Source)
    at javax.swing.JComponent.processKeyEvent(Unknown Source)
    at java.awt.Component.processEvent(Unknown Source)
    at java.awt.Container.processEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.KeyboardFocusManager.redispatchEvent(Unknown Source)
    at java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(Unknown Source)
    at java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(Unknown Source)
    at java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(Unknown Source)
    at java.awt.DefaultKeyboardFocusManager.dispatchEvent(Unknown Source)
    at java.awt.Component.dispatchEventImpl(Unknown Source)
    at java.awt.Container.dispatchEventImpl(Unknown Source)
    at java.awt.Component.dispatchEvent(Unknown Source)
    at java.awt.EventQueue.dispatchEvent(Unknown Source)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
    at java.awt.EventDispatchThread.run(Unknown Source)

We are wokring on to fix this issue, meanwhile if you are facing this problem, you can use the separate_jvm applet parameter to force the java plugin to allocate separate jvm-s for the applets. This solution is working in java 1.6.0_10 and above java versions.

Thank you for your patience, we will notify you in this topic when the fix is ready.

Best whishes,
Istvan

After further investigating the issue, it turns out that the problem occurs with the Viewer applet only and only in the case when legacy_lifecycle is not turned on (it is on by default if you are placeing the applet into a web page with marvin.js). The sketcher applet is not affected at all.

The cause of the problem is the behaviour of the java plugin, and a bug in the Marvin applet base class.

The description of the problem:

Let us have two MarvinView applet, "A" and "B". If "A" is loaded in a browser, and the user left the page where "A" is placed, and navigate to a page where "B" is placed then the java plugin will not restart, "A" is stopped and destroyed, and "B" is initialized and started. This is true in a fairly long time period, not just in the case when switching between the page of "A" to the page of "B", because the browser or the plugin holds the jvm running for a little while thru some kind of caching mechanism. Unfortunatelly the MarvinView applet has an issue and while stopping and destroying it does not stop an executor, and a static reference will be held for that executor. So when "B" is loading, the executor will not be reinitialized because we have a reference to the one which was created by "A". The jvm terminates the threadgroup of "A", therefor the executor will throw an IllegalStateException while "B" trying to submit a task for it while the copy operation is running. In the upcoming version this executor will shutdown correctly when MarvinView applet is being destoryed. If the applet uses the legacy_lifecycle, then this will not occur, because in that case the threadgroup of "A" will be terminated only when the browser is terminating.

The separate_jvm parameter solves the problem because in this case the different applets will have different classloader, and therefore each one will have its own executor separately.

Best regards,
Istvan

I see that the history of changes for Marvin show that this was corrected in version 5.3.7, though I downloaded version 5.3.8 and am getting this same issue occurring.  Setting separate_jvm parameter to true solves the problem, though I would rather not have each applet have its own JVM.  Could you please confirm if version 5.3.8 has this issue resolved.  

 

Thanks,

Jerry

Hi Jerry,

First of all i want to apologize for the long long silence in this topic, i was very busy since we had a lot of work before the commit deadline of the new release, and i had no capacity to dig into this problem enogh deeply until today.

I have found a similar issue in the code somewhere else then the clipboard handling code, but i could not manage to reproduce the problem. Would you provide some more information about the issue to be sure this is the one causing your problems? When the exception occurs, is the stack trace similar, or if different could you provide that to me?

Maybe the best could be if you can provide a test enviroment of your applet, for me to see the problem directly. If that is confidential, the you can send me the link in private e-mail also. If that is impossible, then i can suggest you to test the issue with the new version, and i hope that will solve the problem.

Best regards,
Istvan