Child JVM Processes

Since each Forms runtime process has its own thread within the JVM, there is concurrency. If the JVM reaches a specified number of concurrent requests, it will spawn a child JVM to share the load. Moreover, it's possible to have multiple JVM controllers, each of which may have multiple child JVMs.

For example, different Forms applications need to use different JVMs with different options or classpath. You can specify which JVM controller and Forms application is necessary in the named sections of the Forms configuration file (formsweb.cfg). Alternatively, this information can also be passed as a parameter in the URL for invoking the Forms Application. A form can be configured to use a specific JVM controller using the jvmcontroller parameter. The jvmcontroller parameter indicates to the Forms Runtime process which JVM controller to use. The parameters that need to be used during startup of the jvmcontroller have to be specified in the JVM controller's configuration file, jvmcontrollers.cfg, see Forms Configuration File Settings.

The following figure shows an example of what an environment might look like using JVM pooling. There are two JVM controllers: the first one is using only its in-process JVM, the second one is using three JVMs.

Figure -38 Multiple JVM Controllers with Child Processes

Description of "Figure -38 Multiple JVM Controllers with Child Processes"

Although it's not shown in Figure -38, each JVM controller has a unique name which is used in starting and stopping, or for referencing in the Forms configuration file.

Figure -38 is conceptual only in that it shows different Forms applications using different JVM controllers. However, the Forms runtime process does not communicate with the JVM controller, but directly with one of the available JVMs. Therefore, the first two clients in the diagram can only use the in-process JVM; the rest have three available JVMs to work with.

When the performance of a JVM degrades significantly, it probably means it is servicing too many requests. In that case, it is possible to have multiple child JVMs for the same JVM controller which get created dynamically as needed.

The JVM parameter maxsessions specifies how many Forms runtime processes are allowed to attach to a JVM before a new child JVM is created. When a child JVM is started, it inherits the same parameters as the JVM controller.

If any JVM has maxsessions connections, it does not take any request from new Forms runtime processes. When a new Forms runtime process first attempts to execute Java code, it attaches to a JVM that is available, that is, has fewer than maxsessions connections.

If a JVM reaches maxsessions connections, but another JVM has not, no new JVM is created. If all JVMs have simultaneously reached maxsessions connections, another child JVM is created, and so on.

The scope of a child JVM is within the context of a JVM controller namespace. For example, if you have two JVM controllers, ordersJVM and hrJVM, ordersJVM and its child JVMs do not affect – nor are affected by – hrJVM or its child JVMs.

Child JVM Example

Suppose the JVM controller called ordersJVM has maxsessions=50. Each Orders application that runs sends requests to ordersJVM. Each time a new Forms runtime process sends a request to ordersJVM, a new thread is created that communicates with the Forms runtime process. The JVM controller then returns to listening for new requests. As users end their sessions, the threads in the JVM are also terminated.

When the ordersJVM controller receives the 50th concurrent request (not necessarily the first 50 users because some of them may have quit before the later users started) it will spawn a child JVM. Since it inherits its parent's settings, maxsessions for this child JVM will also be 50. At this stage, the JVM controller has 50 connections, and the child JVM has none.

As new users start this Oracle Forms application and execute Java code, the Forms runtime process attaches to a JVM that is listening within the JVM controller namespace. Since the JVM controller has 50 connections, it is unavailable and the child JVM receives the request. Later, when the parent JVM controller has fewer connections because some users have quit their applications, it is available to receive new requests as long as it has not reached maxsessions connections.

While all this is going on, the hrJVM is operating independently. Overflow connections from ordersJVM will not connect to hrJVM, only to child JVMs of ordersJVM.

Child JVM Management

The JVM Controller can monitor usage and cleanup or remove unused processes when appropriate. This can help to prevent wasting valuable server resources and further improve performance.

By default, this cleanup feature is not enabled. To enable it, set the parameter autoremoval in the JVM Controller configuration. Valid values are listed in the following table.

Table -30 Child JVM Management

Value	Description
OFF (default)	Auto-removal feature is `disabled`. JVMs would not be removed automatically by JVM Controller. The pool size will continue to grow, but not shrink. Child JVMs will continue to live until terminated manually or terminated by the Controller upon its exit.
AGGRESSIVE	Auto-removal feature is `enabled`. The frequency of removing Child JVMs is at its highest. Assuming the JVM can accommodate a maximum of M sessions, in this configuration, the Controller will keep a buffer (spares) of M/2 for accommodating future session requests. One advantage of this setting is that the pool would always have the least possible number of child JVMs to serve the current load plus a maximum of one spare for accommodating future requests. A disadvantage of this setting is that in an active environment (frequent session starts and stops) the frequency of JVMs exiting/creating would be higher. The Controller may become excessively busy managing the children. If all sessions are closed, the pool size would shrink to 1 (the JVM Controller).
MODERATE	Auto-removal feature is `enabled`. The frequency of removing Child JVMs is lower than AGGRESSIVE. Assuming the JVM can accommodate a maximum of M sessions, in this configuration, the Controller would keep a buffer (spares) of M for accommodating future session requests. If all sessions are closed, the pool size would shrink to 1 (the JVM Controller).
CONSERVATIVE	Auto-removal is `enabled`. The frequency of removing Child JVMs is lower than the previous two options. Assuming the JVM can accommodate a maximum of M sessions, in this configuration, the Controller would keep a buffer of 3*M/2 for accommodating future session requests. If all sessions are closed, the pool size would shrink to 2 (the JVM Controller and 1 child).

JVM Load Balancing

To allow connections to be more organized and uniform, a load distribution technique like Round Robin or Least Loaded First or both can be incorporated in the JVM Controller. This load balancing feature is optional and can be configured in the JVM controller configuration file. To use this feature, a set the parameter 'loadbalance' in the configuration file. It can be set with any of the following options:

Least Loaded First
Round Robin
Random

Valid values are described in the following table.

Table -31 JVM Load Balancing

Value	Description
RANDOM (default)	In Random mode, the JVM Controller operates as it did in previous versions. All children created by the Controller are free to accept new connections. Assuming a JVM is available to receive a new connection, it will.
LEASTLOADEDFIRST	In Least Loaded First mode, the JVM Controller monitors and controls the connection accepting behavior of the children JVMs. Only one child JVM would be allowed to listen for new connection requests at a time. To schedule a child JVM, the JVM Controller would iterate though all the child JVMs in the pool and select a child JVM which is serving the least number of sessions. It would instruct the selected child JVM to listen for the next connection request. The scheduled child JVM would acknowledge back to the JVM Controllers after accepting the session request. The JVM Controller would initiate the load balancing sequence again and look for the next least loaded child JVM from the pool.
ROUNDROBIN	In Round Robin mode, the JVM Controller monitors and controls the connection accepting behavior of the children JVMs. To distribute the load, the Controller iterates through the list of JVMs and gives each a fair chance to accept new connection requests. Initially, the Controller would start with the first JVM in the list and instruct it to start accepting connection requests. The JVM Controller would receive the acknowledgment from currently schedule child JVM then move to the next available child available child and initiate the load balancing sequence again. The Controller will cycle through all available JVMs.