Marvin applet loading new JVM rather than using existing

Hi,

I have found that marvin will sometimes load a new Java VM when a webpage is reloaded rather than use the existing JVM which contains the applet. Running under windows on reloading a page containing the applet I can see a new java.exe process start, load and then the existing java.exe process will stop. This adds the overhead of starting java to the applet load time. This does not happen everytime the page is loaded, sometimes the existing JVM is used and the load time is quick.

 

The environment I am experiencing the error is:

Product Version: MarvinSketch 5.2.2
Build Date: 2009-05-26
Operating System: x86 Windows XP 5.1
Java: Sun Microsystems Inc. Java 1.6.0_12
Browser: Firefox 3.0.10 (also IE7)

 

The following output is captured in the java console in the case where reloading the webpage causes the JVM to be reloaded. It covers from when the browser reload button is pressed to the point the first JVM is discarded. The log for the new JVM contains the ouput from a new applet being loaded (I haven't included that here).

 

basic: Starting applet teardown
network: Cache entry not found [url: http://www.surechem.org/chemical/marvin/META-INF/services/com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager, version: null]
network: Connecting http://www.surechem.org/chemical/marvin/META-INF/services/com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager with proxy=DIRECT
network: Connecting http://www.surechem.org:80/ with proxy=DIRECT
network: Connecting http://www.surechem.org/chemical/marvin/META-INF/services/com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager with cookie "__utma=192279976.1778062271.1216007475.1244495473.1244583236.331; __utmz=192279976.1240789253.308.10.utmccn=(referral)|utmcsr=localhost|utmcct=/scws/demo/search.php|utmcmd=referral; PHPSESSID=b0j0jah51cnk57431ma5k62jm7; __utmc=192279976; __utmb=192279976"
network: Cache entry not found [url: http://www.surechem.org/chemical/marvin/META-INF/services/com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager, version: null]
java.lang.InterruptedException
    at java.lang.Object.wait(Native Method)
    at sun.plugin2.message.Queue.waitForMessage(Unknown Source)
    at sun.plugin2.message.Pipe.receive(Unknown Source)
    at sun.plugin2.main.client.MessagePassingExecutionContext.getProxyList(Unknown Source)
    at sun.plugin2.main.client.PluginProxySelector.select(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.plainConnect(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.connect(Unknown Source)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
    at java.net.URL.openStream(Unknown Source)
    at sun.plugin2.applet.Applet2ClassLoader.getResourceAsStream(Unknown Source)
    at com.sun.org.apache.xalan.internal.xsltc.dom.SecuritySupport12$6.run(Unknown Source)
    at java.security.AccessController.doPrivileged(Native Method)
    at com.sun.org.apache.xalan.internal.xsltc.dom.SecuritySupport12.getResourceAsStream(Unknown Source)
    at com.sun.org.apache.xalan.internal.xsltc.dom.ObjectFactory.findJarServiceProviderName(Unknown Source)
    at com.sun.org.apache.xalan.internal.xsltc.dom.ObjectFactory.lookUpFactoryClassName(Unknown Source)
    at com.sun.org.apache.xalan.internal.xsltc.dom.ObjectFactory.lookUpFactoryClass(Unknown Source)
    at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTMManagerClass(Unknown Source)
    at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.<init>(Unknown Source)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.lang.reflect.Constructor.newInstance(Unknown Source)
    at java.lang.Class.newInstance0(Unknown Source)
    at java.lang.Class.newInstance(Unknown Source)
    at javax.xml.transform.FactoryFinder.newInstance(Unknown Source)
    at javax.xml.transform.FactoryFinder.find(Unknown Source)
    at javax.xml.transform.TransformerFactory.newInstance(Unknown Source)
    at chemaxon.marvin.uif.builder.parser.ObjectReader.b(Unknown Source)
    at chemaxon.marvin.uif.builder.parser.ObjectReader.a(Unknown Source)
    at chemaxon.marvin.uif.builder.parser.ObjectReader.a(Unknown Source)
    at chemaxon.marvin.uif.builder.parser.ObjectReader.write(Unknown Source)
    at chemaxon.marvin.uif.builder.DefaultModuleConfiguration.saveShortcutConfiguration(Unknown Source)
    at chemaxon.marvin.uif.module.GUIModule.saveShortcutConfiguration(Unknown Source)
    at chemaxon.marvin.sketch.swing.SketchGUIModule.d(Unknown Source)
    at chemaxon.marvin.sketch.swing.SketchPanel.G(Unknown Source)
    at chemaxon.marvin.sketch.swing.SketchPanel.destroy(Unknown Source)
    at JMSketch.destroy(Unknown Source)
    at AppletLaunch.destroy(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
network: Connecting http://www.surechem.org/chemical/marvin/META-INF/services/com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager with proxy=DIRECT
sun.plugin2.main.client.PluginMain: unrecognized message ID 42
network: Connecting http://www.surechem.org:80/ with proxy=DIRECT
network: Connecting http://www.surechem.org/chemical/marvin/META-INF/services/com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager with cookie "__utma=192279976.1778062271.1216007475.1244495473.1244583236.331; __utmz=192279976.1240789253.308.10.utmccn=(referral)|utmcsr=localhost|utmcct=/scws/demo/search.php|utmcmd=referral; PHPSESSID=b0j0jah51cnk57431ma5k62jm7; __utmc=192279976; __utmb=192279976"
java.lang.ThreadDeath
    at java.lang.Thread.stop(Unknown Source)
    at java.lang.ThreadGroup.stopOrSuspend(Unknown Source)
    at java.lang.ThreadGroup.stop(Unknown Source)
    at sun.awt.AppContext.dispose(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager$AppContextDisposer.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
java.lang.InterruptedException
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:485)
    at com.sun.deploy.util.DeployAWTUtil.invokeAndWait(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager.runOnEDT(Unknown Source)
    at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
basic: Finished applet teardown

 

Thanks for your help,

Richard Koks

Unfortunately, it is a "new feature" of the modern JVM. In earlier Java versions, all applets in the same browser window used the same JVM. In newer Java versions, each applet uses separate JVM that is closed after applet destroy.

We have tested several JVM-s. Our exerience is that this issue appeared in Java 1.5.0_11, since the previous version (1.5.0_10) still shares the JVM among applets. We are seeking after a workaround for this Java issue. But in this moment, I have no tipp how to avoid it.

I do not think that the captured message from the Java console would be relavant in this question. Java drops a false alarm because the following URL does not exist.

http://www.surechem.org/chemical/marvin/META-INF/services/com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager

A factory method from the javax.xml.transform package searches the concrete implementation of a class. It tries loading it from several locations and chooses the first existing one. Actually the warning about the non-existing URL is a sideeffect of Sun's searching mechanism.

We have investigated the issue.

We recommend the following solution for you:

Instead of showing the applet on the landing page on your site, you should display something else at first, so the user will not use the applet immediately, providing a little time for loading  the applet (or at least a part of the jars) in the background. For example, you can display an image first, and start loading the applet in the background; clicking on the image, the applet would display. In case of your site, I think the best solution would be to choose another tab to be displayed when starting the page, which might be either "Basic Text" or "Advanced Text", but put an invisible (0x0 sized) MarvinSketch applet on the main page (i.e. to a place where it is always kept in the DOM).

Another solution is similar in theory to the previous one, but you don't need to create two separate applets: in this case you call the same applet on the main page, setting its width and height attributes to 0 pixel in CSS. When you display the page/tab where you would like to display the applet, from java script you have to set the width and height attributes in CSS to the width and height of the applet element.

Please see the attached example. It demonstrates the second solution.

http://www.chemaxon.com/test/applet-trick/applet.html

We have also investigated the applet's JVM lifecycle issue.

In this forum topic there are a lot of interesting info about this problem.

http://forums.java.net/jive/thread.jspa?messageID=316451&tstart=0

The conclusion is that the applet lifecycle management has reimplemented in newer Java Plugins.

There is an applet parameter that do not let destroy the applet by leaving the web page (unlike the default behaviour of latest versions of Java). The name of this applet parameter is "legacy_lifecycle".

If you give the following applet parameter to your applet, the applet lives until you close the browser window.

<PARAM NAME="legacy_lifecycle" VALUE="true">

You can consider to use this solution. It has both advantages and disadvantages.

I have created a test applet about it. You can try it out: open the page, type an other url into the same window and turn back to the applet page. The JVM is not restarted in this case.

http://www.chemaxon.com/test/legacy_lifecycle.html

We have done further tests for JVM lifecycle with the latest Java: comparing JVM lifecyle with and without the "legacy_lifecycle" parameter.

By default settings:

When the first applet is invoked in a browser, a JVM starts automatically. If you open further tabs or windows with applets and the previous applet is still running, the new applets use the same JVM as the first one. After the last running applet is closed (leave the page where it is embedded to or close the tab or window), the JVM stops automatically. After then, when you navigate to a page where an applet is located, a new JVM is launched.

Using "legacy_lifecycle" parameter:

The situation is similar but the JVM stays alive after closing the last running applet. The JVM terminates when all browser window are closed. Thus an applet is invoked with legacy_lifecycle parameter, any further applets will use the same JVM.

tvertse wrote:

We have investigated the issue. We recommend the following solution for you: Instead of showing the applet on the landing page on your site, you should display something else at first, so the user will not use the applet immediately, providing a little time for loading  the applet (or at least a part of the jars) in the background.

Great idea tvertse I'll give that a try. Plus by doing this people will stay on our sites longer.