EJB pooling in JBoss EAP 6 - Are there any downsides to just setting a really large value for max-pool-size?

Question

We have a large knowledge management application that we are migrating from JBoss EAP 4.3 to EAP 6.4. We had some issues with a parallel MDB-driven process failing (with the error message referenced in this question) which was traced back to exhaustion of the SLSB pool. The MDB threads were requesting a particular stateless session bean three levels deep (to open new transactions), so 10 concurrent processes were enough to exhaust the pool and cause a deadlock with the default max-pool-size of 20.

The solution was to assign that particular SLSB to its own pool and ensure max-pool-size was set large enough so there would always be enough bean instances available (75 in our case, as the culprit MDB process is limited to 25 instances itself). We will doubtless find a lot of other cases in our application that may require or at least benefit from setting up similar custom pool sizes.

The point is, the default value for the MDB and SLSB maximum pool sizes in JBoss EAP - 20 instances of each bean - seems absurdly low. I would like to do some profiling to see how many EJB instances we have in play during typical usage of the application, so I could know what pool sizes we need to allow.

• What is the rationale for the default max-pool-size value of 20?
• Will there be any harm in just setting the max-pool-size of the default slsb-strict-max-pool and mdb-strict-max-pool to some arbitrarily large value? I recognise this could increase the peak memory allocation used by the application if it goes instantiating a lot of EJB instances, but since EJBs are only instantiated and added to the pool on demand, how different is it to the alternative of not using pooling? (For context, I did a quick audit and counted 34 MDBs and 775 SLSBs in our application.)
• Is it best to match the max-pool-size of my EJB pools closely to expected number of EJB instances that the application will require, or can I just set a large max-pool-size value on everything and leave at that?

Answer 1

As to the max-poo-size of 20, it is really hard to come up with a default value. If this were set to 100, then a user on a single core system could easily overwhelm the CPU. It comes down to how many cores are available, what the MDB workload looks like, and how much else is going on in the application.

If you have 32 cores available to you, there is nothing else going on in the application, and the work done during MDB processing is very small, then a pool of 20 is potentially too small.

MDBs will always be pooled, as will stateless session beans.

You can set the pool max to be a high value, and this won't hurt anything. Keeping in mind that for MDBs, a JMS session is needed for activation. The default number of sessions is 15. So for MDBs, you need to match up the number of sessions and the instance pool size in order to get the desired number of activated MDBs. The number of sessions is configured in the MDB activation deployment spec.