Skip to main content

JVM heartbeat Exception

4 replies [Last post]
devilsam
Offline
Joined: 2009-01-28
Points: 0

Hi,

I have an applet and a thread which still executing code after destroy() method. This worked fine until I upgraded to JRE1.6 Update 10 with the new plugin generation.
When I launch my applet, after the call of destroy() method, JVM crashes and the java console prints :
"JVM heartbeat .. Exception, send ts: 5453299147, now ts: 5463298982, dT 9999835"

Is anybody can explain me what happens?
What does hearbeat exception means?

Hope some helps.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cullev
Offline
Joined: 2005-09-07
Points: 0

The problem is with the new plugin not your code, the new plugin kills off the applet if it closes too slowly. Actually affecting thousands of users worldwide whose applets are trying to save state or session information in the stop() or destroy() methods of their applets.
Sun claims that an unresponsive applet is forced to close hard if it doesnt finish what its doing in a fixed period of time. Hence leaving the session in an indeterminate state.
Their change is a prime example of what not to do in software development,
the way forward should have been to provide developers options to make this transition to the new functionality easier, instead of meeting their disbelief with a level of obtuseness (bordering on arrogance) that only beggars belief. http://bugs.sun.com/view_bug.do?bug_id=6559586.
Could Sun not have come to the conclusion that this abrupt termination would have a negative impact on developers?, could they not have said why not allow developers send a heartbeat signal to the jvm every so often until they have finished their task and then if we dont get a heartbeat signal we terminate as normal.

stevekstevek
Offline
Joined: 2004-08-24
Points: 0

We are also seeing this, and it actually is causing a serious problem for our application.

Overview:
========
Our application runs in a browser, and utilizes multiple Java Applets.

The application runs within a browser window with multiple frames.

Typically, one applet runs for the lifetime of the browser window, and various actions that are taken, different HTML documents may be loaded in different frames which load several other Applets (up to 4 shorter-lived applets). These applets all rely on the shared classloader paradigm for inter-applet communication.

In one test case, which we can repeat, what we're finding is this:

a) A user loads our application and the "main" applet.
b) The user performs the action that causes the other applets to load.
c) The user performs the action that causes the other applets to unload (their HTML documents are replaced).
d) The user performs the action that causes the other applets to be reloaded.

Between (c) and (d), users running plugin2 will end up with a NEW JRE to reload the other applets. This, of course, breaks the inter-applet communication.

Running plugin2 with tracing on shows that the plugin has the JVM heartbeat exception:
JVM heartbeat .. Exception, send ts: 5817799876, now ts: 5827705667, dT 9905791

Does anyone have any clue how to go about avoiding this?
What are the causes of this happening?
How does this heartbeat mechanism work?

From looking at the bugparade bugs I've seen, it seems that some things like problems during applet unloading can cause this. In our applet, we do something like this in destroy():

public void destroy()
{
Log.info( "... MyApplet destroy() ..." ) ;
SwingUtilities.invokeLater( new MyRunnable( DESTROY ) ) ;
}

Could this cause the Heartbeat exception?

slowintegra
Offline
Joined: 2009-05-28
Points: 0

https://jdk6.dev.java.net/6uNea.html download link

jre 1.6 update14 fixed our Heartbeat issue

richardmauri
Offline
Joined: 2008-09-08
Points: 0

I have a similar problem with next generation 1.6 plugin.
I'm using 1.6.0_11 and in my applet's close() a worker thread is invoked (to signal polite close to it's appserver peer) and the close() thread then waits to be notified.

In my case, the symptom is the applet jvm is exited almost immediately before the close() get's notified.
Also, note that if close() is blocked like this that destroy()is not invoked.

In the log file I see the same JVM heartbeat exception message.

P.S. When I comment out the blocking call in close() that destroy() IS called....

Message was edited by: richardmauri