4.3. Remote EJB Clients

The configuration options discussed so far apply to both local and remote clients, but there are additional configuration options that needs to be considered where remote clients are concerned: maxPoolSize and clientMaxPoolSize. Local clients use the local interface of stateless and stateful session beans, so the execution of those methods is done on the incoming connectors' thread pool. Remote clients call the remote interfaces of stateless and stateful session beans, interacting with the platform's remoting solution. It accepts connections from remote clients, marshals the arguments and calls the remote interface of the corresponding bean, whether that is a stateless or stateful session bean. Note that the minimal configuration does not have the remoting service deployed.
The configuration file is remoting-jboss-beans.xml, in the directory JBOSS_EAP_DIST/jboss-as/server/<PROFILE>/deploy, an extract of which is below:
<!-- Parameters visible only to server -->
<property name="serverParameters">
   <map keyClass="java.lang.String" valueClass="java.lang.String">
   <!-- Selected optional parameters: -->
   <!-- Maximum number of worker threads on the      -->
   <!-- server (socket transport).  Defaults to 300. -->
   <!--entry><key>maxPoolSize</key> <value>500</value></entry-->
       <!-- Number of seconds after which an idle worker thread will be    -->
       <!-- purged (socket transport).  By default purging is not enabled. -->
       <!--entry><key>idleTimeout</key> <value>60</value></entry-->
       </map>
</property>
The most important parameter here is the maxPoolSize parameter which specifies the number of worker threads that will be used to execute the remote calls. The comments state that the default is 300, which is quite large, but that depends on the number of remote clients, their request rate, and the corresponding response times. Just like any other connector, the number of clients calling the server, their request rate, and the corresponding response times need to be taken into account to size the pool correctly. One way to determine this is to monitor the statistics on the client to see how many invocations occur. For example, if the remote client is a stateless session bean on another server, the JMX console contains invocation statistics that could be examined to determine how many concurrent calls are coming from that client. If there are many remote servers acting as clients then statistics have to be obtained from each remote client. To change the pool size, uncomment the line and set the value.
Consider the opposite case, where the client is the local server, calling another remote server. There is a matching pool parameter called clientMaxPoolSize, specified in the same configuration file as above:
<!-- Maximum number of connections in client invoker's    -->
   <!-- connection pool (socket transport).  Defaults to 50. -->
   <!--entry><key>clientMaxPoolSize</key> <value>20</value></entry-->
In this example the parameter is present but commented so the default value of 50 applies. To change the value, uncomment the line and change the value to the desired value.
To determine the required value it's necessary to understand how many concurrent calls are being made to remote beans. Depending on the method used, there is some monitoring you can do. For example, if the remote bean invocations are being made from a local stateless session bean the JMX console statistics can be used. Included are the statistics for that stateless session's bean and concurrentCalls value to see how many concurrent invocations are being made, as in the following example:
JMX Console - JMX MBean View

Figure 4.2. JMX Console - JMX MBean View

The screenshot shows the attribute InvokeStats and it has an attribute value that shows the InvocationStatistics class, and the value concurrentCalls equals 14. This could give you a hint about how many client connections need to be available in the pool.