Recently two of our clients have reported problems with our applets. Looking at the java plugin console it is full of ClassNotFoundException so none of our code is executed.
I've been able to reproduce the stack trace using a virtual pc image with 0 free space on disk, but the problem goes away as I restore some disk space, and the users tell me that their disk is not full; they are able to create new files.
Our applet requires java 6, and the problem has appeared with updates 1, 10 and 14 of the jre. We have also tried different browsers (IE and Firefox), clearing the browser and java caches, ...
How can I debug or trace what is the jvm doing to load our applet?
I suppose that the problem lies on some security directive on windows so I'm using Sysinternal's Process Monitor to log the activity but I don't really know where to look at.
The Java cache is most likely messed up. Open Java in the Control Panel and get rid of all temporary files to see if it goes away.
Logging in the Java Console for loading applets can be enabled which helps quite alot (even if the plugin is extremely cryptic). See http://java.sun.com/javase/6/docs/technotes/guides/deployment/deployment-guide/tracing_logging.html
I've been looking at the plugin source from the JDK and I've found that there is additional debug info available in the logs setting the environment variable JPI_PLUGIN2_DEBUG.
Unfortunately I still only see ClassNotFound exceptions.
I've found a piece of the plugin code that swallows all exceptions, so maybe my users problem is there...
had similar problems a while ago. In our case, the problem seems to be how the applet tag is set up on the web page. If it is in a wrong order or contains the codebase attribute, it fails with 6u10+. This works for us:
<applet name="DMGANTT" archive="DMGantt.zip" code="dm.applet.DMGanttApplet"
width='100%' height='100%' mayscript="mayscript">
We had a similar problem with one of our clients. We discovered that it was a strange bug in some versions of Java related to proxy configuration on the client. See this article for the details
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6723715
Also, our applet failed with new versions for a different reason.
Now, in similar cases I ask them to check javatester.org, so that I can see if applets (in general) load OK in their browser. If that page loads OK, its a problem on our applet (or page). Else it's a problem in their configuration. I help them anyway but it's easier to debug.
Related
See here for original question.
I'm writing a Java service, using Jetty for Webserving and SQLite for database storage. Source is available here.
I found that, although the service ran stably from my laptop, when deployed to an EC2 instance it would crash with no obvious error message in output somewhere between 1 hour and 2 days from starting up. I added some logging options to the startup call (-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=...), and got this crashlog.
This is the first time I've encountered such a file, and at first glance it doesn't seem very obvious which part of it refers to the actual error and which parts are just giving contextual information, so I'd really appreciate any good guides to understanding it. In particular, it looks like it's trying to interact with ZipFiles, which I don't use in my project.
This answer links to a blog which was -1'd in the answer comments
This answer links to some Oracle documentation, which I would normally be overjoyed at, but it appears to be a general debugging guide - can't see anything in there about hs_err files (though that may become clear on further reading)
This result from Google claims that "whatever Java code you execute, JVM should never crash. If it does, it is just a JVM bug. So try to log a defect with Sun with all details and hopefully they will look into that.", which sounds pretty absolutist - I think it's highly unlikely that my little toy project has uncovered a JVM bug!
Crashes in Java_java_util_zip_ZipFile_getEntry are most often caused by concurrent access to .zip files, e.g. a file is overwritten while an open instance exists.
See JDK-8042197, JDK-8031691 for details.
BTW, as to original question, here is a presentation on JVM crash dump analysis.
Looking at the crashlog, it appears that something you were unpacking (jar file or zip file) resulted in a JVM crash.
If this occurs during startup, try adding this to your JVM command line to see which file it was possibly working on.
java -verbose:class [more command line]
i have noticed that signed applets are loaded much slower with the latest plugin (included in java 8u31 and 7u75). I have debugged the situation quite a lot and i found out that the problem is directly related to the size of the jar files that are referenced in the jnlp file. The problem is that each time the applet starts, there is some 're-indexing' of the cached jar files that takes time.
To reproduce the issue i did this:
I created a minimal applet and in the jnlp file i used to deploy it, I added several irrelevant .jar files (that are not even referenced, so the classloader does not load them) of considerable size (e.g. 30MB). Of course i am using versioning in the jnlp and capture all http traffic to make sure that the delays are not because of traffic (either re-downloading or certificate revocation checks, etc). I run the applet with the trace enabled and then went through the xml trace log file and found out where the delays come: they are always from the JarSigningVerifier ....
Has anyone else seen something like that?
It is very easy to see and reproduce this behavior and i wonder if there is something i am overlooking. Having worked on applets for the past years extensively, i am totally lost at what can be happening. I can verify that reverting to the previous version of the plugin (and every other version before) works as expected.
I have submitted a bug report with oracle, but i haven't heard back still. Any info or idea will help,
TIA
Same here. I thought already I'm getting crazy. Thanks for sharing this.
We are using Java Web Start, but it's sharing the same problem of re-indexing all jar files (in our case it's an app with quite some jars, so starting takes ages).
Aside from the fact that Oracle suddenly decided to check the certificate of the deploy TLS, which caused some hickup on Linux and Macs (we used a StartSSL certificate there, which isn't included in the Java keystore - on Windows it works as it uses the platforms root certs, too).
And, to make it even worse, on Windows x86 the 8u31 silently dies if -XX:+DoEscapeAnalysis or -XX:+OptimizeStringConcat is present in the JVM arguments, though both parameters are standard in Java 8 (but not in 7, that's why they've been included, still). The 64bit engine doesn't have that problem.
The next thing they changed is they now overwrite the start icons if they've been changed (we changed them to put the 64bit engine's path in there), so it stubbornly changes the path back to the 32bit engine every time.
The behaviour of Oracle is not helpful at all, as they didn't announce any of these changes in their changelogs, let alone announcing the certs changes a few days ahead.
I would like to hear from anyone who's sharing the problems and possible workarounds.
Patric
Have you been able to solve this issue? Have you had a reaction from Oracle?
UPDATE START
I've tried everything I can think of and haven't managed to solve the
issue, so I posted my own question on this issue.
A similar bug report can be found here and is backported to at
least Java 8u51 which I tested. Yet again they managed to increase
startup time for our application.
END UPDATE
We are using Java Web Start for an Eclipse RCP-based application with jars that are all signed.
Startup time is 8s within the IDE, Java version doesn't seem to matter here. With web start the story is different. It becomes (much) worse with every Java update:
7u?? (<60): +2s (10s)
7u60: +5s (13s)
7u75: +15s (23s)
8u31: +12s (20s)
8u40: +21s (29s)
8u51: +23s (31s)
Have you tried your jnlp without versioning? In my experience Java jnlp is very buggy specially if you change the jnlp default values. Versioning support is disabled by support, so try it without versioning and see if it still slow?
For me, I noticed some bugs when I used update="background" value, so I no longer change the default update method. My theory is that Oracle only tests jnlp against default values before they release new Java versions.
We've got a signed java applet that is called from as aspx via javascript (We're not really a Java development shop, were mainly C# devs).
I'm needing to debug through this applet but I'm having an isue that is not beeing seen on my colleagues machines.
To attach the netbeans debugger to the applet we've traditionally removed all certifcates from the 'Trusted Certificates' store via the Java Control panel, deleted any cached applets (via the Java Control Panel) and then when the applet is downloaded and run, we see the security warning. At this point we able to attach the netbeans debugger, okay the security warnings (not checking the 'always trust' checkbox) and then having hit a breakpoint within the applet code, debug from there.
However, whatever I do I'm not seeing the security warnings, which makes it a bit hard to attach to the applet. I've removed our certificate, zapped any cached applets, I've even 'clutched at straws' and removed and reinstalled the JDK (we're using 1.6 update 7, update 10 and update 20; all updates we know work with our implementation). I just can't get the security warning to appear.
It's like I've got an 'always trust' flag permanently switched on.
Any ideas gratefully received.
The security warning comes only when the applet is signed. Otherwise the applet does not have any privileges, so it is not considered necessary to show the warning.
You could simply sign your applet with a new (untrusted, self-signed) key, maybe this helps.
You might try launching the applet using (non-embedded) Java Web Start. Launching with JWS you will lose JS functionality, but should regain easy control over the permissions.
Sorry, not a direct answer to your question, but if what you want is to pause the JVM at startup for debugging, you could use the suspend=n option in the JVM options, as in something like:
-Djava.compiler=NONE -Xnoagent -Xdebug -Xrunjdwp:transport=dt_socket,address=2502,server=y,suspend=n
That way, the JVM suspends automatically, waiting for a connection from the debugger.
I'm having some problems tracing the reason that I can't load a java(fx) applet.
The java plugin console for the browser has always been my sole source of information for problem solving. The reason it isn't much help at the moment is that the applet starts to load, downloading the jar files and outputting a percentage to the console along with the occasional statement to say it's on the next jar file. At some point in time (different percentages each time) the console just closes unexpectedly and the applet stops loading. I know this isn't much to go on but I was wondering if there was any way that the output from the console could be stored to a file on the local machine. To debug this particular problem, changing security permissions temporarily would be acceptable.
The problem has occured on every pc i've tried, however if I keep refreshing after failure it seems to cache the jar files previously downloaded and thus get further through the loading process until it eventually works. My issue now is that on a particular customers network refreshing does not resolve the issue. I thought it may be a permissions issue writing to disk but I've tried an administrator account and still no luck. I've also tried a variety of browsers. It might also be worth noting that they go through a proxy server - when the applet tries to load it asks for the credentials for logging on to the proxy which seems to authorise fine.
If anyone has a suggestion on what I could try it would be gratefully received.
Thanks,
James
Two points:
You should be able to get a stack trace through the applet console viewer (which runs in the system tray on PC's) and if you open that up it will show you your stack trace for debugging.
Can you reproduce this problem using the Java Applet Viewer tool? This will allow you to write unit tests, and debug much more easily.
I forget where it is, but somewhere in the java control panel (one of the options under the advanced tab I believe) there's an option to turn on logging. This will log all output to the java console to a file as well. I've used this when trying to debug issues similar to this.
There's some info here on where the files will appear:
http://download.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/tracing_logging.html
The problem ended up being some JS code that was making calls to the applet before the applet had initialised.
I am working on a demo for a client of what's possible with GWT-Ext for GWT. After browsing for the simplest way to get up and running, I decided on installing the Google Plugin for Eclipse and using the New Web Application Wizard.
First time around, I followed these steps for create the default application:
Selected File > New > Web Application Project from the Eclipse menu.
In the New Web Application Project wizard, entered a name for the project (ExtDemo) and a java package name, com.extdemo.
Unchecked the "Use Google App Engine" check box.
Clicked Finish.
Right clicked it in package explorer and selected Run As > Run Configurations
Put a check in the Automatically Select Unused Port checkbox.
Clicked Run to see the default GWT 1.7 application
This worked fine... it launched GWT's hosted browser and the app worked as supposed to.
(I then continued to import GWT-Ext and add all sorts of widgets building up a nice little demo app)
However at some point when relaunching the app in hosted mode, the hosted browser displays an empty iframe. I even reverted the code to a point where everything was working as supposed to and... same thing, an empty iframe with the surrounding static content.
Now what is really strange is when I go through the process of creating the default application again by following the steps above, the hosted browser launches with an empty iframe again.
However when I click on Compile/Browse, this sometimes allows the app to launch in Firefox.
Anyone have this happen to them?
I have seen some odd behaviors occasionally. Here are some basic suggestions (some are dumb and you might have tried them already):
Use a new workspace
I do not know if GWT plugin somehow caches stuff in the embedded Jetty. If you are re-creating the default app/project, try and use a different name for the project.
Try and re-use a fixed port so that there is no possibility of having multiple servers running.
Update: Found a new "classic" solution:
Delete the cache in IE and possibly Firefox too. Apparently the 'script' tag content tends to be cached by IE. If this works, we can all try tearing our hair out!
Found the updated answer at this link:
I have had the same problem in the past and found it is much more likely to happen if limited CPU is available. For example if my older laptop was running on battery and had stepped down the CPU speed to save power it frequently happened. When running on mains in max performance mode it only happened occasionally. Now I have a much newer and more powerful laptop and the problem has gone away.
Another cause I found was too many breakpoints set up in eclipse and removing breakpoints would often clear the problem.
I've had issues with the browser caching.
Try clearing your browser cache, refresh a few times after a failed load, etc.
You can also try using a different port so the URL is different.
It takes some time to download and run the GWT app, particularly if you are using extra libraries, so wait for a few seconds to see if the app finally loaded.
What makes the app loading to fail randomly is something I don't know yet, but I suspect, as stated by Daniel Vaughan, that is related with a lack of computer resources, CPU, memory, etc.