Java – Glassfish Server4 maximum pool size and max wait time

glassfishjava

The Glassfish4 server installed on my machine has Maximum Pool Size = 32 connections. Two cron jobs are scheduled from my application after every 10 and 15 mins on this server. The server crashed after 2 hours with the exception "java.sql.SQLException: Error in allocating a connection. Cause: In-use connections equal max-pool-size and expired max-wait-time. Cannot allocate more connections."

So, I altered the JDBC Connection pool settings and put in really large numbers just to see what would happen.

Maximum Pool Size: 1000000000 (1 billion)
Max Wait Time: 300000 (5 minutes)

Now my cron jobs are running fine.

Do you think having set the JDBC Connection pool attributes this high could cause issues? Please advise what values will be optimum.

Best Answer

I have resolved this issue with below settings in Glassfish4

Initial and Minimum Pool Size:16

Maximum Pool Size:64

Pool Resize Quantity:4

Idle Timeout:60

Max Wait Time:3000

I enabled connection leak monitoring in Glassfish4.

After enabling connection leak monitoring, when I checked the monitored data after some time, I could see ConnectionLeak exception in logs in some of my java classes. I closed the connections in these classes as they were being made directly from Connection object and JPA Entity Manager was not used in them.

Now all my cron jobs are running without Server crash.

Related Solutions

Java – change the max-pool-size for connections, and what determines what I should set it to

How to know how much connection the application is currently using

You don't give enough information to answer that. Most appservers will have some sort of JMX reporting on things like this. Alternatively, depending on the database, you could find the number of currently open connections.

what should be the optimal connection pool settings for a heavily traffic applicaiton

Higher than what you've got?

The above of course assumes that you're not mishandling connections. By that I mean if you're using them directly in code you should always use this idiom:

Connection conn = null;
try {
  conn = ... ; // get connection
  // do stuff
} finally {
  if (conn != null) try { conn.close(); } catch (Exception e) { }
}

If you're not released connections back to the pool and are waiting for the garbage collector to clean them up and release them you're going to use way more connections that you actually need.

Java – way to release a saturated connection pool

Before doing so, figure out why the connections are not released properly. Sounds like there is a single place where this is forgotten (do you have all close() in finally clauses?).

I can strongly recommend Michael Nygards "Release It!" for techniques to make software production ready.

EDIT#1: If I understand your description correctly your backend programs go in MSGW in QSYSOPR which results in a hanging connection until the response is given which in your case is close to never. Is it an option to use a profile with a default reply of "C" which allows the fault to propagate to you as an exception?

Otherwise you may be able to set a timeout period for either the connections or for the whole server of 24 hours? Then at least the connections will eventually be closed. This solution does not scale though, but may make development easier.

Please note, it is also possible to have a separate surveillance thread which looks for MSGW's regularily and send them an answer automatically AFTER grabbing the call back stack for post mortem analysis.

Best Answer

Related Solutions

Java – change the max-pool-size for connections, and what determines what I should set it to

Java – way to release a saturated connection pool

Related Topic