We have a set of Java applications that we have been developing for years that are launched remotely via Web Start. After updating to Java SE 8 Update 91 there is a very significant pause (20-60 seconds depending on the application) in the startup process with no indication to the typical user that anything is happening. This pause occurs after Java's "Starting Application" dialog closes and before the application is launched.
The length of the pause appears to be correlated with the size of the application. Reverting to Java 8 Update 77 eliminates the pause altogether, and these same applications start without any pause.
Our applications do request "all-permissions" as we need to read/write data to the client's drive for caching purposes. So all of our jars are signed and have the necessary manifest modifications.
If your Java settings have the Java console enabled then the console is displayed immediately following Java's "Starting Application" dialog that appears when the application's JNLP file is accessed. However, no activity is seen in the console during this pause (for instance none of the typical Java class loading messages appear until after the pause and none of our code in the "main" method is executed until after the pause).
Some of these applications are fairly large. The code we've written is about 10-12MB, and additional resources total between 15-20MB depending on the application.
I found a JDK bug report that sounds very similar... bug report
This report states that using an older Java version results in instant startup if the Java cache is removed before the first start. The issue that I'm reporting does not seem to be impacted by the Java cache. Reverting to Java 8 Update 77 results in instant startup without deleting the Java cache.
The Java release notes for Java 8 Update 91 mention a bug fix "Regression in Applet startup time fixed". But I don't see anything that would indicate an intentional change that would result in a long pause during startup (such as increased security scanning, etc).
With this length of pause in startup and no ability to indicate to the user that something is happening we are getting complaints about the applications.
Any help would be greatly appreciated.
UPDATE July 1, 2016...
I found this SO question that seems to describe the identical symptoms: similar issue. However, it was related to Java 7 Update 40. And the resolution was to disable the revocation check in the deployment.properties file.
I have used the Java console to set "Do not check" for both "Perform signed code certificate revocation checks on" and "Perform TLS certificate revocation checks on". And I checked to make sure that the changes are reflected in the deployment.properties file. However, these setting do not fix or improve the issue at all.
If this had worked it would be a great indicator of the problem, but it would not be a useful "solution" to have clients turn off these revocation checks in their advanced settings. It especially wouldn't be helpful for the general public that have access to a number of our applications.
UPDATE July 7, 2016...
Based on the comment by jaivalis I downloaded the early access release of the Java 8 Update 112 JRE. When I run our applications with this JRE there is no pause at all. The applications run immediately after the "Starting Application" dialog closes.
So far I can't find any notes that explain why this would be. I am hoping this "fix" isn't the result of new security measures that have not been completely applied to this early access release. I'm hoping that something has actually been addressed and that the immediate launch performance will remain when this release is official.
By the way I cannot find an official release date for Java 8 Update 112. I was hoping it would happen in July, but I see some indications of October. Anyone have any information on when this update will be generally available?
Here is the early access page for Java 8 Update 112 early access
Here is the release date info I found Java 8 Update 112 release timeline
This page also mentions a Java 8 Update 102, but I can't find an early access release for that update. Any links I find point to the 112 update.
This issue has been resolved with the Java 8 update 101 release (technically build 1.8.0_101-b13).
Hello I found something that might help you :)
In the recent patch notes from Oracle it stated that this was a bug issue in the last patch of Java
Personally I would find a third-party to download a previous version of java
Here is a link to the patch notes
http://www.oracle.com/technetwork/java/javase/8u20-relnotes-2257729.html
Hope you find the issue!
Related
I use Eclipse to run my application only. I use an external editor (Atom) for my main development. I turned on "Refresh using native hooks or polling" to have Eclipse refresh regularly (more info here on how to do that).
My problem is... on OSX (MacBook Pro), it's a 15 sec delay. On my old crappy PC, it's pretty much instant.
My question, is there any way to speed up the polling time on OSX?
(I am not on a Mac, so I can't test this for you.)
Zend have written a refresher for Eclipse that uses Java 7 new features.
https://github.com/zendtech/studio-workspace-refresher
There are others out there to (https://github.com/zch/AutoRefresher and https://github.com/psxpaul/EclipseJava7Refresher) but based on the age and source of the zend one it is where I would start.
Note that you have hit upon one of the biggest issues people have with Eclipse. The new (as of Oct 2015) Friends Of Eclipse funding is aiming to tackle some of these issues. This one has a bug you can track Bug 480551.
There is no configuration that changes the operation of the polling refresh used on the Mac (org.eclipse.core.internal.refresh.PollingMonitor).
The refresh runs much quicker on Windows because it uses file system native hooks rather than polling.
You have to contract for supporting non public available Java releases with Oracle for example Java6 ended with 1.6.0_45 publicly but with support you can use 1.6.0_80. Our aim is to stay supported and public available java platform. Therefore we want to migrate our jnlp based RIA application from Java6 to java8 platform. In migration testing we have experienced performance problem. We try to simulate this problem in Java 8 poor GUI performance compared to Java 6 but we realize that the problem not related the that question.
After the introduction, in order to find out the root cause of problem we profiled the application with java mission control(jmc) bundled with jdk. when we profile application launched at workspace we cannot see any performance degradation. And then we realize that problem occurs only JAVAWS environment. Our application runs as expected at java environment but in javaws environment some GUI's are really slow , it adds 6 seconds more to response time.
My first question is that how we profile java application launched by javaws? Because to use jmc we need to set some JVM arguments (java-vm-args="-XX:+UnlockCommercialFeatures -XX:+FlightRecorder") but javaws doesn't support this JVM parameters. You can find supported list at here
My Second question is that why application doesn't run identical at both environment(java and javaws)? We examined signed and unsigned version of our application and both have same situation. By the way our application uses all-permission.
You can pass any JVM arguments you want to javaws by typing them in:
Java Control Panel > Java > View > Runtime Parameters
As for the poor performance, are you referring to application load time? or is it also slow after the applicatio is started?
If you're talking about load time, then yes javaws is slower (about 3-5 seconds slower) because it has to contact Internet to check if your jar files are black listed or if the certificate is expired. I'm not sure exactly what it is doing in these few seconds but I agree that it is disappointing performance hit and I hope someone can shed more light on it.
Thanks Saeid. Problem is determined. We profiled finally and we found that javaws consume long time to load resources e.g. icons, images. to make a solution we cached the resources and for absence images we return a empty image.
You can see this at
To profile application launched by javaws we make a solution following steps in ubuntu
1. move java executable javam
2. create a script file named java and insert following script
#!/bin/bash
/full/path/of/javam XX:+UnlockCommercialFeatures -XX:+FlightRecorder "$#"
3. run application and check java is launched by ps -ef | grep javam
4. run jmc and profile it.
I have a java webapp, built with Lucene, and I keep getting various "file already closed" exceptions - depending on which Directory implementation I use. I've been able to get "java.io.IOException Bad File Descriptor" and "java.nio.channels.ClosedChannelException" out of Lucene, usually wrapped around an AlreadyClosedException for the IndexReader.
The funny thing is, I haven't closed the IndexReader and it seems the file descriptors are going stale on their own. I'm using the latest version of Lucene 3.0 (haven't had time to upgrade out of the 3.0 series), the latest version of Oracle's JDK6, the latest version of Tomcat 6 and the latest version of CentOS. I can replicate the bug with the same software on other Linux systems, but not on Windows systems and I don't have an OSX PC to test with. The linux servers are virtualized with qEmu, if that could matter at all.
This seems to also be load related - how frequently this happens corresponds to the amount of requests/second that Tomcat is serving (to this particular webapp). For example, on one server every request completes as expected until it has to deal with ~2 reqs/sec, then about 10% start having their file descriptors closed from under them, mid-request (the code checks for a valid IndexReader object and creates one at the beginning of processing the request). Once it gets to about 3 reqs/sec, all of the requests start failing with bad file descriptors.
My best guess is that somehow there's resource starvation at an OS level and the OS is cleaning up fds... but that's simply because I've eliminated every other idea I've had. I've already checked the ulimits and the filesystem fd limits and the number of open descriptors is well below either limit (example output from sysctl fs.file-nr: 1020 0 203404, ulimit -n: 10240).
I'm almost completely out of things to test and I'm no closer to solving this than the day that I found out about it. Has anyone experienced anything similar?
EDIT 07/12/2011: I found an OSX machine to use for some testing and have confirmed that this happens on OSX. I've also done testing on physical Linux boxes and replicated the issue, so the only OS that I've been unable to replicate this issue with is Windows. I'm guessing this has something to do with POSIX handling of file descriptors because that seems to be the only relevant difference between the two test systems (JDK version, tomcat version and webapp were all identical across all platforms).
the reason you probably don't see this happening on Windows, might be that its FSDirectory.open defaults to using SimpleFSDirectory.
check out the warnings at the top of FSDirectory and NIOFSDirectory: the text in red at http://lucene.apache.org/java/3_3_0/api/core/org/apache/lucene/store/NIOFSDirectory.html:
NOTE: Accessing this class either directly or indirectly from a thread while it's interrupted can close the underlying file descriptor immediately if at the same time the thread is blocked on IO. The file descriptor will remain closed and subsequent access to NIOFSDirectory will throw a ClosedChannelException. If your application uses either Thread.interrupt() or Future.cancel(boolean) you should use SimpleFSDirectory in favor of NIOFSDirectory
https://issues.apache.org/jira/browse/LUCENE-2239
I've built a RCP-based application, and one of my users running on Windows XP, Sun JVM 1.6.0_12 had a full application crash. After the app was running for two days (and this is not a new version or anything), he got the nice gray JVM force exit box, with exit code=1073807364.
He was away from the machine at the time, and the only thing I can find near that time in the application logs was some communication with the database (SQL Server by way of Hibernate). There's no hs_ files or anything similar as far as I can tell. Web searching found a bunch of crash reports with that exit code in a variety of applications, but I didn't see any fundamental explanation of what causes it.
Can anyone tell me what causes it? Is there additional information likely to have been dumped that could prove useful?
From what I can tell, this error code (0x40010004) arises in all sorts of situations, with (as you noted) no obvious common thread.
However this page says "0x40010004" means "the task is running"! So, I would surmise that the correct way to interpret it is as saying "this tasked has exited in a way that prevented it setting a proper exit code".
I don't know if this will help, but I would try looking in the Windows Event logs to see if the problem is being reported there.
When a Java VM crashes with an EXCEPTION_ACCESS_VIOLATION and produces an hs_err_pidXXX.log file, what does that indicate? The error itself is basically a null pointer exception. Is it always caused by a bug in the JVM, or are there other causes like malfunctioning hardware or software conflicts?
Edit: there is a native component, this is an SWT application on win32.
Most of the times this is a bug in the VM.
But it can be caused by any native code (e.g. JNI calls).
The hs_err_pidXXX.log file should contain some information about where the problem happened.
You can also check the "Heap" section inside the file. Many of the VM bugs are caused by the garbage collection (expecially in older VMs). This section should show you if the garbage was running at the time of the crash. Also this section shows, if some sections of the heap are filled (the percentage numbers).
The VM is also much more likely to crash in a low memory situation than otherwise.
Answer found!
I had the same error and noticed that others who provided the contents of the pid log file were running 64 bit Windows. Just like me. At the end log file, it included the PATH statement. There I could see C:\Windows\SysWOW64 was incorrectly listed ahead of: %SystemRoot%\system32. Once I corrected it, the exception disappeared.
First thing you should do is upgrade your JVM to the latest you can.
Can you repeat the issue? Or does it seem to happen randomly? We recently had a problem where our JVM was crashing all over the place, at random times. Turns out it was a hardware problem. We put the drives in a new server and it completely went away.
Bottom line, the JVM should never crash, as the poster above mentioned if your not doing any JNI then my gut is that you have a hardware problem.
The cause of the problem will be documented in the hs_err* file, if you know what to look for. Take a look, and if it still isn't clear, consider posting the first 5 or 10 lines of the stack trace and other pertinent info (don't post the whole thing, there's tons of info in there that won't help - but you have to figure out which 1% is important :-) )
Are you using a Browser widget and executing javascript in the Browser widget? If so, then there are bugs in some versions of SWT that causes the JVM to crash in native code, in various Windows libraries.
Two examples (that I opened) are bug 217306 and bug 127960. These two bug reports are not the only bug reports of the JVM crashing in SWT, however.
If you aren't using the Browser widget then these suggestions won't help you. In that case, you can search for a list of SWT bugs causing a JVM crash. If none of those are your issue, then I highly recommend that you open a bug report with SWT.
I have the same problem with a JNLP application that I have been using for a long time and is pretty reliable. The problem started immediately after I upgraded from Windows 7 to Windows 10. According to my investigation, it is most likely a bug in Win 10.
The following is not a solution, but an ugly workaround. In jre/bin directory, there is javaws.exe. If I right-clicked /Properties/Compatibility and ticked Run this program as an administrator, the JNLP app started to work.
Please, be aware that this approach could cause security issues and use it only if you have no other option and 100% know what you are doing.