5.2.1 Estimating the resources used by J2EE server

(a) Basic number of threads

The formula is as follows:

• For a J2EE server

  Maximum-number-of-threads = 76+A+B+C+D+E+F+G+H+I+J+K+L+M+N+O+P+Q+R+S

• For a batch server

  Maximum-number-of-threads = 73+D+E+F+G+H+I+O+P

Legend:

• A: Total number of deployed Entity Beans

• B: Maximum number of instances of Message-driven Bean when using Message-driven Bean (Total of instances when multiple Message-Driven Beans exist) ^#

  #: Value of <pooled-instance><maximum> in the Message-Driven Bean property file

• C: Maximum-number-of-EJB-clients-performing-remote-invocation ×2+Total-number-of-maximum-concurrent-requests-of-each-EJB-client +1

• D: Number of threads of CORBA Naming Service (=number-of-connections-between-client-and-CORBA-Naming-Service ×2+number-of-requests-received-concurrently +number-of-threads-generated-during-initialization (if the value of vbroker.agent.enableLocator is true, then 6, if the value is false, then 4) +1)

  However, added only when CORBA Naming Service is invoked as in-process (Specify inprocess in the ejbserver.naming.startupMode key of usrconf.properties).

• E: Maximum number of database connections used concurrently

  If the connection pooling functionality is used, the maximum number of connection pools (value of MaxPoolSize specified in the Hitachi Connector Property file. Total of connection pools if there are multiple resource adapters) is used as the value.

  If the connection pooling functionality is not used, the value is obtained from the maximum number of concurrent requests or the number of connections used for each request (if one connection is used for one request, the maximum number of concurrent requests is used as the value).

• F: Maximum number of concurrently executed transactions, if the JTA transaction is used (one thread is used for each transaction in which a transaction timeout occurs. In the case of one request in one transaction, the maximum number of concurrent requests is used as the value)

• G: Maximum-number-of-connection-pools^# (total of connection pools if there are multiple resource adapters) × 2

  #: Value of MaxPoolSize specified in the Hitachi Connector Property file

• H: Number of resource adapters using the connection pooling functionality

• I: Number of threads used for the conclusion and recovery processing of a global transaction (add 16 if a global transaction is used)

• J: Number of deployed Web applications

• K: Number of threads used in the automatic reload functionality of a J2EE application

  Specify one of the following values:

  • For ejbserver.deploy.context.reload_scope=app, and ejbserver.deploy.context.check_interval=1 or more

    Number-of-running-J2EE-applications-in-exploded-archive-format + Number-of-WARs-included-in-running-J2EE-applications-in-exploded-archive-format × 2

  • For ejbserver.deploy.context.reload_scope=web, and ejbserver.deploy.context.check_interval=1 or more

    Number-of-WARs-included-in-running-J2EE-applications-in-exploded-archive-format × 2

  • For ejbserver.deploy.context.reload_scope=jsp, and ejbserver.deploy.context.check_interval=1 or more

    Number-of-WARs-included-in-running-J2EE-applications-in-exploded-archive-format

• L: Number of threads of the TP1 inbound adapters calculated using the following formula: (4 + number-of-threads-specified-in-TP1-inbound-adapter-property-rpc_max_thread_count + number-of-threads-specified-in-TP1-inbound-adapter-property-trn_max_thread_count + total-number-of-deployed-Message-driven-Bean-(services)-integrated-with-TP1-inbound-adapters + number-of-threads-specified-in-TP1-inbound-adapter-property-MaxTPoolSize)

  Add only when using the TP1 inbound integrated functionality. This thread count can be controlled by the Hitachi Connector Property file. The number 4 added at the beginning is the number of threads used internally for the TP1 inbound integrated functionality.

• M: Sum of the maximum number of thread pools used for invoking the asynchronous Session Beans (Value of <cosminexus-app><ejb-async-props><max-thread-pool-size> in cosminexus.xml)

• N: Sum-of-the-number-of-J2EE-applications-containing-asynchronous-Session-Beans × 2

• O: If settings are specified to start the thread that manages the reply receiving thread (vbroker.ce.iiop.ccm.htc.threadStarter=true), add 5.

• P: Add the following value if settings are specified to control the closing of connections when a timeout occurs (vbroker.ce.iiop.ccm.htc.readerPerConnection=true):

  (Number-of-J2EE-servers-with-remote-invocation-destination-EJBs + 1) × 2 If CTM is used, add the following values in addition to the above:

  • For scheduling of J2EE applications

    Number-of-running-J2EE-applications + 1

  • For scheduling of Stateless Session Beans

    Number-of-Stateless-Session-Beans-to-be-scheduled + 1

• Q: Maximum number of threads of the NIO HTTP server (the value of webserver.connector.nio_http.max_threads)

• R: Maximum number of threads used by Java Batch

  Add only when running an application that uses Java Batch.

  Specify the value of ejbserver.javaee.batch.executorService.JNDI-name.maxThreads. If multiple JNDI names are defined, specify the total of the values for each JNDI name.

• S: Maximum number of threads used by Concurrency Utilities for Java EE

  Add only when running an application that uses Concurrency Utilities for Java EE.

  This value is the total of the following values. If multiple JNDI names are defined, specify the total of the values for each JNDI name.

  • Maximum number of ManagedExecutorService threads

    (The value of ejbserver.javaee.concurrent.managedExecutorService.JNDI-name.maxPoolSize)

  • The maximum number of tasks executed concurrently by ManagedScheduledExecutorService

  • The maximum number of threads generated concurrently by ManagedThreadFactory

The following figure shows the example estimation when CORBA Naming Service is started as in-process and Cosminexus HTTP Server is used.

Figure 5‒1: Example estimation of the number of threads when Cosminexus HTTP Server is used

The following is an example of estimating the number of threads for using Cosminexus HTTP Server shown in the figure.

Formula for calculating the number of threads, when CORBA Naming Service is started as in-process and Cosminexus HTTP Server is used

Maximum-number-of-threads = 76+A+B+C+D+E+F+G+H+I+J+K+L+M+N+O+P+Q+R+S

The results calculated using the above formula and the contents that are set up are as follows:

Maximum-number-of-threads = 76+0+0+1+5+72+72+144+2+0+2+0+0+0+0+0+0+100+0+0=474

Table 5‒13: Contents estimated for the number of threads when Cosminexus HTTP Server is used (Example)

Setup item	Set value	Explanation
A	0	Sets 0 because Entity Bean is not used.
B	0	Sets 0 because Message-driven Bean is not used.
C	1	A remote invocation is not performed. Also, if the EJB is invoked locally from a Web application, the threads are not generated for executing the EJBs.
D	4+1	Such as C, the EJB client-related value is 0.
E	48+24	--
F	72	Sets the value of MaxClient, which is the maximum number of concurrent requests, if there is one request in one transaction.
G	(48+24) × 2	--
H	2	--
I	0	Sets 0 because the global transaction is not used.
J	2	--
K	0	Sets 0 because the application is not in the exploded archive format.
L	0	Sets 0 because the TP1 inbound adapter is not used.
M	0	Sets 0 because the asynchronous Session Bean is not used.
N	0	Sets 0 because the asynchronous Session Bean is not used.
O	0	Sets 0 because the settings for receiving the response message using a dedicated thread are not specified.
P	0	Sets 0 because the settings for controlling the closing of connections are not specified.
Q	100	--
R	0	Sets 0 because Java Batch is not used.
S	0	Sets 0 because Concurrency Utilities for Java EE is not used.

(b) Number of threads used according to JavaVM option specifications

According to JavaVM option specifications, calculate the maximum number of threads using the following formula. Add A only when -XX:+UseG1GC option is specified, and add B only when -XX:+HitachiUseExplicitMemory option is specified.

Maximum-number-of-threads = A + B

Legend:

• A: Number of threads used by G1 GC (Value specified in -XX:ParallelGCThreads option. When this option is not specified, the default value of -XX:ParallelGCThreads option based on the number of logical CPUs. Note that the value is determined by the number of logical CPUs that exist when starting the J2EE server. Hence, the number of threads does not change even if the number of logical CPUs changes after the server is started.)

• B: Number of threads used by the Explicit Memory Management functionality (The number of logical CPUs. However, this number is 8 when the number of logical processors is 8 or more. This number is determined by the number of logical CPUs that exist when starting the J2EE server. Hence, the number of threads does not change even if the number of logical CPUs changes after the server is started.)

For the JavaVM options, see the following sections in the uCosminexus Application Server Definition Reference Guide:

• 14.5 Java HotSpot VM options that can be specified in Cosminexus

• -XX:[+|-]HitachiUseExplicitMemory (Explicit Memory Management functionality option)

(a) Number of threads generated during initialization

The number of threads generated during initialization is 6, when the value of vbroker.agent.enableLocator key of usrconf.properties is true and 4, when the value is false. The vbroker.agent.enableLocator key is setup as true automatically when the CTM integration functionality is enabled (true is specified in ejbserver.ctm.enabled key)

(b) Number of worker threads

The number of worker threads is the total of number-of-requests-received-concurrently + 1 and number-of-connections-between-client-and-CORBA-Naming-Service × 2.

The keys related to worker threads are as follows:

• vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMax

• vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMin

• vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMaxIdle

These keys are specified as value of ejbserver.naming.exec.args key of usrconf.properties. For details on the keys, see the manuals Borland(R) Enterprise Server VisiBroker(R) Developers Guide and Borland(R) Enterprise Server VisiBroker(R) Programmers Reference.

The number of worker threads when maximum value is specified in the vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMax key is the total of maximum-value-specified-in-this-key and number-of-connections-between-client-and-CORBA-Naming-Service.

However, when minimum value of worker threads is specified in the vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMin key, and when the total number of worker threads is not within that minimum value, consider the number of worker threads equal to the minimum value.

When the maximum value is not specified, the worker threads increase in multiples. However, the worker threads lapse when they exceed the time specified in the vbroker.se.iiop_tp.scm.iiop_tp.dispatcher.threadMaxIdle key (Default value is 300 seconds) from the time they are idle, resulting in reduction in the number of threads with the reduction in load.

When the maximum value of number of worker threads is specified and when the number of threads is the same as the maximum number of worker threads, do not perform error handling for the requests received from this point of time but continue the process as follows:

• Continue the process for received requests.

• Do not read() the new requests from the socket and retain these requests in the receive buffer of TCP and send buffer at the client side. When the TCP buffer is full, the requests would wait to be sent from the client side.

When the worker thread being processed is NULL (Responded), the next request reception is processed.