We have tried to run dummy and simple java applet in HTML and could repeated the issue.
Our test steps as below:
1. Started IE to run the dummy HTML with applet. Only one java.exe could be found on task manager. Using "jps" to check, the java.exe main class was "PluginMain" which should be the plug-in process. The commit charge usage was about 550M/1226M
Started around 50 Winzip processes. The commit charge usage would gradually 2. increased to about 850M/1226M
3. Then we found the java.exe process was terminated.
We tried on 2 machines with P4 2.8GHz CPU and 512MB RAM with same result. Therefore we believe the issue comes from JRE7 next-generation plugin itself.
The cause is unlikely to be Java 7.
Java does not use or depend on McAfee and updating McAffee files on the systems is not going to affect things, from the VM's perspective. If the app itself is using files related to McAffee, that is a different issue. Since Java 6u10 the new plugin has been the default. The process run outside of the browser, while is why more java.exe processes are being seen.
I suspect that there is something going on with McAffee... along the lines of detecting the JRE as a virus or malware. We have seen that happen from a signature matching the running generating a false positive. Or custom rules created and rolled out as part of a deployment. I would look to see if McAffee is using Java processes to update the signatures and then killing of all running Java processes when it completes.
You would review the Applet pages. They cover debugging as well as compatability with older JREs.
Thanks Roger for your reply.
As mentioned on my reply, we tried to not start McAfee update but started around 50 Winzip processes to increase memory usage, the result was same.
I'm in the final stage of a migration Forms 6i->11gr2 patchset 1 JVM 220.127.116.11. Large enterprise system with 250 fmb and 1300 users used all around the province in Canada (lan, wan, vpn, ...).
All the migration is automated with FormsAPI scripting and I can deploy in parallel until summer 2014. So I have 6i and 11gr2 in production and I switch users gradually from 6i to 11gr2. Now I have about 300 users who runs with Forms 11gr2.
The deployment of the JVM is automated with SCCM and we deploy the family 6 and 7 (18.104.22.168 and 22.214.171.124) because Forms patchset 1 support 126.96.36.199+ and 188.8.131.52+.
I have had a lot of problems with these JVM. I used some java arguments (2d3d, sortmerge, xms, xmx) to fix freeze/crash !
My last PROBLEM is the same you have. I have this with JVM 184.108.40.206. I will try JVM 220.127.116.11 with 5 users during a week or two and I will post the results.
At this time, do you have a solution for this problem ?
Hi, our solution is to "disable the next-generation plug-in". After that the problem could be avoided. Hope it helps you.
I use this high CPU simulator http://www.fossiltoys.com/cpuload.html
I tested the JVM 18.104.22.168 and 22.214.171.124 and I have the problem again.
Depending what I do in the form when the java.exe stop due to the high cpu, the trace file show different stack trace. But this stack trace is more common :
It seems to have a problem with java threads accessing cookie.
network: Cookie service is not available - use cache to determine "Cookie"
java.io.IOException: namedPipe shutdown
at sun.plugin2.message.transport.NamedPipeTransport$SerializerImpl.flush(Unknown Source)
at sun.plugin2.message.transport.NamedPipeTransport$SerializerImpl.writeByte(Unknown Source)
at sun.plugin2.message.AbstractSerializer.writeShort(Unknown Source)
at sun.plugin2.message.AbstractSerializer.writeChar(Unknown Source)
at sun.plugin2.message.AbstractSerializer.writeUTF(Unknown Source)
at sun.plugin2.message.helper.URLHelper.write(Unknown Source)
at sun.plugin2.message.CookieOpMessage.writeFields(Unknown Source)
at sun.plugin2.message.transport.SerializingTransport.write(Unknown Source)
at sun.plugin2.message.Pipe.send(Unknown Source)
at sun.plugin2.main.client.MessagePassingExecutionContext.doCookieOp(Unknown Source)
at sun.plugin2.main.client.MessagePassingExecutionContext.setCookie(Unknown Source)
at sun.plugin2.main.client.PluginCookieSelector.setCookieInBrowser(Unknown Source)
at com.sun.deploy.net.cookie.DeployCookieSelector.setCookieInfo(Unknown Source)
at com.sun.deploy.net.cookie.DeployCookieSelector.put(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
at oracle.forms.net.HTTPNStream.doPost(Unknown Source)
at oracle.forms.net.HTTPNStream.doFlush(Unknown Source)
at oracle.forms.net.HTTPNStream.flush(Unknown Source)
at java.io.DataOutputStream.flush(Unknown Source)
at oracle.forms.net.StreamMessageWriter.run(Unknown Source)
I will try with JConsole and see if there is more information when the process stop.
The fix for me is also to disable the next generation plugin ! But I will log a SR to Oracle.
I will not be surprise that the native plugin (next generation disabled) will also fix some intermittent bugs I have (sticky cursor, ...) !!!
So my 5 users in prod will test the next generation disabled.
I wondering if I will have to set the java arguments I used with the next generation plugin enabled ? Do you know ?
-Xms256m -Xmx256m -Dsun.java2d.d3d=false -Dsun.java2d.noddraw=true -Djava.util.Arrays.useLegacyMergeSort=true -Djava.net.preferIPv4Stack=true
Thanks a lot.
I just tried on Windows 64 bits, JVM 64 bits. I don't reproduce the problem !!!
And I red it's not possible to disabled the next generation plugin on Windows 64 bits. It's a good chance it works nice !
But in our 1300 users, of course there is Windows 32 bits et 64 bits. Only new PC are 64 bits for these users.