The formula for calculating number of threads is as follows. The total of (a) and (b) is the number of threads used by J2EE server.
(a) Basic number of threads
The formula is as follows:
- When invoking the CORBA Naming Service as in-process and when using the in-process HTTP server
Maximum-number-of-threads = 70+A+B+C+D+E+F+G+H+I+K+L+M+N+O+P+Q+R+S
- When invoking CORBA Naming Service as in-process and when using Cosminexus HTTP Server
Maximum-number-of-threads = 68+A+B+C+D+E+F+G+H+I+J+K+L+M+O+P+Q+R+S
- 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 clients connected concurrently to a Web server (total of clients if multiple Web servers are used)
If a Web server is restarted while a request is being processed, and a large number of requests are received after the server is restarted, the generated threads might exceed this value.
- K: Number of clients connected concurrently to a simple Web server
However, the number of clients connected concurrently are specified as 5 when the clients connected concurrently to a simple Web server are less than 5 and when they are 100 and above, 100 is specified.
- L: Number of deployed Web applications
- M: 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
- N: Number of threads of an in-process HTTP server (Added only when the in-process HTTP server functionality is used. The number of threads of an in-process HTTP server can be controlled by the J2EE server user definitions (usrconf.properties)) #
#
Maximum value: Value of webserver.connector.inprocess_http.max_connections
Regular value: Number-of-concurrent-requests-from-Web-client + value-of-webserver.connector.inprocess_http.min_spare_threads
- O: 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.
- P: 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)
- Q: Sum-of-the-number-of-J2EE-applications-containing-asynchronous-Session-Beans
2 - R: If settings are specified to start the thread that manages the reply receiving thread (vbroker.ce.iiop.ccm.htc.threadStarter=true), add 5.
- S: 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
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
![[Figure]](figure/zu050100.gif)
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 = 68+A+B+C+D+E+F+G+H+I+J+K+L+M+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 = 68+0+0+1+5+72+72+144+2+0+72+5+2+0+0+0+0+0+0=443
Table 5-28 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 webserver.connector.ajp13.max_threads, 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 | 72 | Sets the value of MaxClient in the case of a Web server (Linux). |
K | 5 | Sets the minimum value because the simple Web server is not used. |
L | 2 | -- |
M | 0 | Sets 0 because the application is not in the exploded archive format. |
O | 0 | Sets 0 because the TP1 inbound adapter is not used. |
P | 0 | Sets 0 because the asynchronous Session Bean is not used. |
Q | 0 | Sets 0 because the asynchronous Session Bean is not used. |
R | 0 | Sets 0 because the settings for receiving the response message using a dedicated thread are not specified. |
S | 0 | Sets 0 because the settings for controlling the closing of connections are not specified. |
(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:+UseParNewGC 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 parallel copy garbage collection.
- (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 management heap 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:
- 16.5 Java HotSpot VM options that can be specified in Cosminexus
- -XX:[+|-]HitachiUseExplicitMemory (Explicit management heap functionality option)
This section describes the estimation of number of threads of CORBA Naming Service generated on J2EE server when invoking the CORBA Naming Service as in-process while invoking the J2EE server.
Estimate the number of threads of CORBA Naming Service as follows when invoking the CORBA Naming Service as in-process:
Total-number-of-threads = number-of-threads + worker-threads-generated-during-initialization
(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.