7 Replies Latest reply: Sep 2, 2013 1:25 PM by stephane_parenteau RSS

    JRE7 plug-in process ends suddenly during McAfee signature update

      Hi guys,

      We found a problem that using JRE1.7 next-generation java plug-in, the plug-in processes sometimes terminates suddenly when system resource drop down.

      Our system uses a dozen applets. Previous we are runnig on JRE1.5. We are now upgrading to JRE1.7 with next-generation plug-in enabled.
      McAfee Virus Scan is a mandatory anti-virus software running in our PCs. When the McAfee signature update starts, it occupies a lot system resource and the performance will extremely drop down.

      Comparing to old generation plug-in, we noticed there are 2 extra java.exe processes run when using the new plugin. By using "jps" to check, these 2 processes' main class are MainPlugin.

      Our test machine is P4 2.8G CPU + 512MB RAM. Before the mcafee signature update process started, the commit charge usage was around 600M/1260M. After the mcafee signautre update process started, the commit charge usage gradually went to about 1100M/1260M. And then plug-in processes ended. The IE showed an error "Target applet or JVM process exited abruptly". The applets could no longer be used.

      We re-tested with next-generation disabled. Although the system performance would also be quite slow but the applets could still run.

      Therefore we suspected that the plug-in processes would end by itself if system resource is not enough. Our questions are:

      1. what is the minimum system resource for the plug-in process?

      2. is it possible to adjust the minimum system resource requirement?

      Thanks a lot!
        • 1. Re: JRE7 plug-in process ends suddenly during McAfee signature update
          Hi all,

          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.
          • 2. Re: JRE7 plug-in process ends suddenly during McAfee signature update
            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.

            • 3. Re: JRE7 plug-in process ends suddenly during McAfee signature update
              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.
              • 4. Re: JRE7 plug-in process ends suddenly during McAfee signature update



                I'm in the final stage of a migration Forms 6i->11gr2 patchset 1 JVM 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 ( and because Forms patchset 1 support and


                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 I will try JVM 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 ?



                • 5. Re: JRE7 plug-in process ends suddenly during McAfee signature update

                  Hi, our solution is to "disable the next-generation plug-in". After that the problem could be avoided. Hope it helps you.

                  • 6. Re: JRE7 plug-in process ends suddenly during McAfee signature update

                    I use this high CPU simulator http://www.fossiltoys.com/cpuload.html


                    I tested the JVM and 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.

                    • 7. Re: JRE7 plug-in process ends suddenly during McAfee signature update

                      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.