5 Replies Latest reply on Mar 24, 2014 8:28 PM by Michael Ferrante-Oracle

    Forms Consuming 100% of cpu at client desk top


      We have Custom Oracle forms application on Forms 10gR2 on window 2003 server

      and it is pointed to a database 11g db.

      The custom forms are accessed by the user using IE8 URL.

      The issue is when the forms are accesed the client desktop CPU utlisation goes to 100% and stays there for a while.

      Then it stays between 30 to 60% even if we are not doing any activity on the form.

      When we explored further we can see that it spawns off a constant 46 java.exe threads and these threads are consuming cpu and making it 100% , 60% even when it idle.

      The threads are not dieing.

      Where are the threads orginating. We don't have any custom built in Java calls in the forms.

      Any direction on

      1. Why 100% cpu utilization even when idle.

      2. What is generating a high number of  java.exe threads on the client desktop when the forms are accesed.

      3. Why java.exe threads are not dieing when there is no action.



        • 1. Re: Forms Consuming 100% of cpu at client desk top
          Michael Ferrante-Oracle

          I think before diving too deep into how many threads are running and what they are for, you need to look closely at expected behavior and compare it to what you are seeing.  So, for example, in my environment where my client is Win7(x64) using IE10 and Java7u51, I too see around 40-45 threads on the java.exe process hosting any form I run.  However the difference in my environment is that when the form is idle (untouched), the CPU usage remains under 2% and most often 0 or 1%


          The fact that you are seeing a high CPU usage suggests one of the following:


          1.  The machine does not have sufficient RAM available.  Try testing on a machine that has significantly more resources.

          2.  Another process (e.g. virus scanner) is causing the problem.

          3.  You application is doing something that is not visible to the UI.  For example, a repeating and/or running or expiring Forms timer.

          4.  You have enabled Forms tracing, debugging, netStats.

          5.  You have set HEARTBEAT to inappropriate value.  For example a fraction of a minute.

          • 2. Re: Forms Consuming 100% of cpu at client desk top

            This is good info.

            We did set Heatbeat to 12 min. in formweb.cfg and default.env and web.xml the session-timeout to 60. The form timed out in 12 min.

            But still idle time cpu is 35%

            it's still java.exe(Java(TM) Platform SE binary )and we know the PID

            We checked for Ram and we have 8gb of Ram at client ,

            We don't have a virus scanner, I even made the apps server a trusted site

            There is no forms timer trigger. I searched for timer in .fmb

            there is no tracing or debugging

            • 3. Re: Forms Consuming 100% of cpu at client desk top
              Michael Ferrante-Oracle

              We're getting closer, but there's still some information missing.  For example, exactly which Forms version, browser/version, and Java version are you using AND does this behavior reproduce on a machine running a different operating system or different hardware?


              Also, FORMS_TIMEOUT and HEARTBEAT should never be set to the same values.  HEARTBEAT should always be at least 2 smaller than FORMS_TIMEOUT.  As I mentioned, be very careful that you haven't incorrect set these values.  For example,  .12 - adding an accidental decimal point will cause problems.


              If you are not using the very latest Forms version for the family you have, I highly recommend installing the latest (last) patch available.  Remember that Forms 10 is no longer supported.  Therefore, the last patch was released a long time ago, but should be properly installed if not already.  The last patch for 10.1.2 was (patch ID 5983622).  If you already have installed, have you followed the instructions in the MyOracleSupport note  1058514.1?  If not, I recommend doing so.


              After the release of, Forms specific "Bundle" patch was released.  It included over 100 fixes.  Contact Support for the latest details on obtaining this patch and to understand what prerequisites it has.

              • 4. Re: Forms Consuming 100% of cpu at client desk top

                Thanks..the information is helpful , still it mistery why 100% cpu utilization and mutiple java.exe threads.

                After setting the heartbeat we are able to solve the forms timeout issue..

                But cpu is still 100% for a long time may be 3 min. even if there is no activty + before it start to drop.

                If you can tell us what is building multiple java.exe for a single executable we may be able to solve the problem.


                as asked..


                form version: Forms [32 Bit] Version (Production)

                Browser Version: IE8

                Versiob 6 Update 45 (build 1.6.0-45-b06)


                client (my desktop):

                form version: Forms [32 Bit] Version (Production)

                Browser Version: IE8

                Versiob 7 Update 51 (build 1.7.0-51-b13)


                • 5. Re: Forms Consuming 100% of cpu at client desk top
                  Michael Ferrante-Oracle

                  "....what is building multiple java.exe for a single executable..."


                  You didn't mention this before.  First, this really has nothing to do with Forms.  This is related to how the Java Plugin work and likely produces the same behavior with any applet.  I would not expect to see more than one java process for each applet you start.  So if you open more than one tab, likely you will see more than one java process.  In most cases, if you do this and exit a browser tab.  The java process previously associated will remain alive until you completely exit the browser session.  Keep in mind that a browser "session" may consist of more than one browser windows.  If you are attempting to use the separate_jvm applet parameter, this too will result in more java processes laying around.