Oracle Forms Session Exception Stack trace

Problem Description: Forms session disconnects continuously

Forms Error FRM-92102 occurs after 50 to 55 users connected to application.
This prevents further users logging in and prevents use of current users who a
reconnected.

Symptoms:

Application Log file shows:

Forms session <93> exception stack trace:
java.io.IOException: FRM-93000: No HTTP headers received from runform

Explanation:

This problem can occur due to the scalability issue that the system is not able
to share the resources among the concurrent users and Windows has exceeded the
capacity of the operating systems Non-IO Desktop heap resource.

Windows has limitation on the heap alocation and usage..
It is the expected behaviour when too many users are trying to access the
application.

Solution:

Change the logon-property from the responsible service to
"[x] Allow service to interact with desktop"
(using all the defaults of the registry!).

This forces the Apache Service (Forms 6i) or the Oracle Process Manager Service 
(Forms 9i and above) to use the IO Desktop heap which is larger than
the Non-IO Desktop heap by default. The term "Desktop", here, is not to be
confused with the normal Windows desktop, which holds your icons and your
background, etc. In this context, it is Microsoft terminology for an area of
memory.

If more heap resource is needed, then the appropriate heap resource can be modified in the Registry

1. Modify the appropriate variable in the registry. This should not be done
unless:

- A backup has been made of the registry. Any error in modification of the
registry can render the system unusable.
- Solution 1 has been tested and has increased the number of processes
that will run successfully.

The following information applies to Windows NT, Windows 2000.
From the HKEY_LOCAL_MACHINE sub tree, go to the following key:

\System\CurrentControlSet\Control\Session Manager\SubSystems

Select the Windows value.From the Edit menu, choose String. Increase the
SharedSection parameter. SharedSection specifies the system and desktop
heaps using the followin g format:
SharedSection=xxxx,yyyy,zzzz

The default values are 1024,3072,512

Example :

Set the value to something like 1024,2048,2048

All the values are in kilobytes (KB).

xxxx = System-wide Heapsize. There is no need to modify this value and
it is ignored for the rest of this discussion.

yyyy = IO Desktop Heapsize. This is the heap for memory objects in the
IO Desktop.

zzzz = Non-IO Destop Heapsize. This is the heap for memory objects in
the Non-IO Desktop.

If you change these values, you must reboot the system.

Programs that get run as a service or which are spawned from a service fall
into the Non-IO Desktop, and therefore consume memory from that heap. All
other programs, such as those run from an icon or from a command line, or get
spawned from those, consume memory from the IO Desktop heap.

For server-style applications, such as a database, or Forms, a service has
the advantage that a user can logout and the program continues to run.

If you can't run any more processes, then you should increase the relevent
heap. Using the Forms examples in this bug, if you start Apache / Oracle
Process Manager from the command line, then it consumes memory from the IO Desktop heap.
Then for each user, there is a Forms runtime process spawned, which also
consumes memory form the IO Desktop heap.In the case of this bug, the memory
ran out after 483 users. The solution would be to increase the relevant heap.
As stated earlier in this bug, when it was changed to 5112 KB (from the default
of 3072 KB), more than 700 users were able to run concurrently. Note that
changing the Non-IO Desktop heap (the 512 KB) would achieve nothing in this
case.

The converse is also true. If the Apache / Oracle Process Manager process were
started as a service, then the third value, Non-IO Desktop heap, would have to
have been increased.

The values are recommended to be a multiple of 512, but this isn't necessary.
There is a hard limit of 48 Mb, which is the total heap size for Windows. But
it seems unlikely that you will need to go this high.

If you increase the Non -IO Desktop heap and your server is dedicated to Forms
or some other server process , then you can safely decrease the IO Desktop heap
since that is just wasted. This isn't necessary, though.

In summary, if you are hitting this problem where your server can not create
any more processes, you should increase the heap size of the either the IO
Desktop or the Non-IO Desktop. The correct one depends on how you run your
application, whether from a service, or from an icon or command line.

You have to restart the all services from Oracle AS, after saving the changes.

There are several parameters that need to be set inorder to tune the application.

So please folloe the below Action Plan also further improve the performance the application.

1. Check Are the users logging off without closing the sessions properly.

2. Take the process id and check which IP address is using the process and then
talk to the person with the IP address what they were running.
memory leak

3. Set forms_timeout and heartbeat and make sure the sessions are killed with an x mins of inactivity

Also what can be done:

1) Please note that for the session time out there is three parameters, which need to handle. Those are

FORMS_TIMEOUT
heartBeat
session_timeout

1) Please specify the forms_timeout=5 parameter in you env file and specify the heartBeat=10
parameter in your basejini.htm (incase if you are using JRE specify the parameter in basejpi.htm) file.

2) Please note that you need to set the Session_Timeout in web.xml file.

set in the web.xml file in OracleAS --> j2EE --> OC4J_BI_Forms --> applications -->
forms90app or formsapp -->forms90web or formsweb --> Web-inf

The purpose of the parameters to set forms_timeout and heartbeat parameters, is if the users keep
the session ideal for some x time, then to kill the sessions automatically in that x time.

References:

Note 549735.1 Description List For Parameters Affect Timeout In Webforms

"Out of Memory" error message appears when you have a large number of programs running

When you run a large number of Windows-based programs, "Out Of Memory" error messages appear when you attempt to start new programs or try to use programs that are already running, even though you still have plenty of physical and pagefile memory available.

Cause

This behavior can occur if the desktop heap in the WIN32 subsystem is depleted.

Note This problem occurs more often under Windows NT 3.5 as the default size of the desktop heap is 512K. Under Windows NT 3.1 the default value is 3072K. The default was reduced to increase performance.

Resolution

To correct this problem, increase the size of the desktop heap:

1.       Run Registry Editor (Regedt32.exe).

2.       From the

HKEY_LOCAL_MACHINE

subtree, go to the following key:

\System\CurrentControlSet\Control\Session Manager\SubSystems

3.       Select the Windows value.

4.       From the Edit menu, choose String.

5.       Increase the SharedSection parameter.

For Windows NT:
SharedSection specifies the system and desktop heaps using the following format:

SharedSection=xxxx,yyyy

Add ",256" or ",512" after the yyyy number.

For Windows 2000, Windows XP, and Windows Server 2003:
SharedSection uses the following format to specify the system and desktop heaps:

SharedSection=xxxx,yyyy,zzzz

For 32-bit operating systems, increase the yyyy value to "12288";
Increase the zzzz value to "1024".
For 64-bit operating systems, increase the yyyy value to "20480";
Increase the zzzz value to "1024".

More Information

Windows NT uses a special memory heap for all Windows-based programs running on the desktop. The desktop heap is used for all objects (windows, menus, pens, icons, etc.). When a large number of Windows-based programs are running, this heap may run out of memory. When there is not enough memory to satisfy an allocation request, the system normally returns an error and notifies the user that they are running low on memory. Some programs do not handle the failure gracefully, and in some cases there may not be enough memory to create the error message dialog box. As a result, the requested operation fails without any indication.

The SharedSection key is a long string when viewed using Registry Editor. The default value for this key is as follows.
   %SystemRoot%\system32\csrss.exe
   ObjectDirectory=\Windows
   SharedSection=1024,3072,512
   Windows=On
   SubSystemType=Windows
   ServerDll=basesrv,1
   ServerDll=winsrv:GdiServerDllInitialization,4
   ServerDll=winsrv:UserServerDllInitialization,3
   ServerDll=winsrv:ConServerDllInitialization,2
   ProfileControl=Off
   MaxRequestThreads=16

The first SharedSection value (1024) defines the heap size common to all desktops. This includes the global handle table (Window handles are unique machine wide) and shared system settings (such as SystemMetrics). It is unlikely you would ever need to change this value.

The second SharedSection value (3072) controls the size of the desktop heap that is associated with an interactive window station (used for Windows objects). This static value is used to prevent ill- behaved applications from consuming too many resources. Because the desktop heap is mapped into each process' address space, this value should not be set to an arbitrarily high value (as it would decrease performance), but should only be increased sufficiently to allow all the desired applications to run.

The third SharedSection value (512) controls the size of the desktop heap for each desktop that is associated with a "non-interactive" window station. If this value is not present, the size of the desktop heap for non-interactive window stations will be same as the size specified for interactive window stations (the second SharedSection value).
For more information about the parameters of the SharedSection key, click the following article number to view the article in the Microsoft Knowledge Base:

184802 PRB: User32.dll or Kernel32.dll fails to initialize

Ref: http://support.microsoft.com/kb/126962
------------------------------------------------
It is very important to remember to only increase the default heap size for non-interactive services as much as is necessary to support the amount of users (RFgen Clients) you have. The total heap size available to all Windows sessions is a pool of 48 MB. As all non-interactive services use the same heap size, increasing the default heap size will effectively reduce the overall number of services/sessions you can run on the PC. To increase the default heap size for non-interactive services, you must make an edit in Windows registry.

The first value defines the system heap size, the second controls the size of the interactive desktop heap (used for Windows objects) and the third value (e.g. "1024,3072,512") covers the non-interactive desktop heap. All values are KBytes. If the 3rd value is not present non-interactive desktops will default to the same value as interactive desktops (typically 3072 K).

In Vista SP1 or Windows Server 2008 this increases to 12 MB:

HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows
SharedSection=1024,12288,512
64-bit Windows has a default interactive desktop heap size of 20MB 

Microsoft does not recommend that you set a value that is over 20,480 KB for the second SharedSection value. Because the non-interactive desktop heap is mapped into the address space of each and every process, this value should not be set to an arbitrarily high value but should only be increased sufficiently to allow all the desired applications to run.

Lower values increase performance at the risk of crashing any process which may run out of resources. 

For many applications (in Win XP), 3072K is too high although MS recommends 512 K (in Q142676) and for many applications this is too low.