0

You have already established that the 'disconnect after certain idle time' setting works for bonecp. Now you need to analyze your code to see why is it taking up multiple connection objects for a single request (assuming that what's happening here). You don't need 4 test clients for this. Fire up your app and without sending across requests check how many connection objects are created. After that just send across a single request and then check how many connection objects you have.

It's quite possible that bonecp initializes all the connections eagerly resulting in a full pool. So basically from this point it's either:

  1. Your app isn't releasing connections in a timely manner
  2. Your bonecp configuration is causing the eager initialization of the entire pool
0

Like you said below is the capture when the app is fired up without any connection to it yet.

11 instances of "com.mysql.jdbc.JDBC4Connection", loaded by "sun.misc.Launcher$ExtClassLoader @ 0xf6d9e3d8" occupy 748,352 (14.94%) bytes.

Biggest instances:

•com.mysql.jdbc.JDBC4Connection @ 0xf670e550 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6738ec8 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf675de60 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf67889f8 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf67ad7c8 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6810d50 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6835bd8 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf685d1a8 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6881f48 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf68a6de0 - 68,032 (1.36%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf68cbb48 - 68,032 (1.36%) bytes. 


Keywords
com.mysql.jdbc.JDBC4Connection
sun.misc.Launcher$ExtClassLoader @ 0xf6d9e3d8

Next I just make one single connection just with one data only I can see the connection increase to 13.

13 instances of "com.mysql.jdbc.JDBC4Connection", loaded by "sun.misc.Launcher$ExtClassLoader @ 0xf6d9e3d8" occupy 884,336 (16.19%) bytes. 

Biggest instances:

•com.mysql.jdbc.JDBC4Connection @ 0xf670e550 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6738ec8 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf675de60 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf67889f8 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf67ad7c8 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6810d50 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6835bd8 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf685d1a8 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6881f48 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf68a6de0 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf68cbb48 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf6b839d0 - 68,032 (1.25%) bytes. 
•com.mysql.jdbc.JDBC4Connection @ 0xf68f0940 - 67,952 (1.24%) bytes. 
These instances are referenced from one instance of "java.util.concurrent.ConcurrentHashMap$Segment[]", loaded by "<system class loader>"

Keywords
com.mysql.jdbc.JDBC4Connection
java.util.concurrent.ConcurrentHashMap$Segment[]
sun.misc.Launcher$ExtClassLoader @ 0xf6d9e3d8

Details »

Then I purpose make a second connection and the it remains to be 13.

0

This might be just how bonecp manages the pool i.e. create connections eagerly though that still doesn't explain in the increase from 11 -> 13 given that it already had 11 connections to spare. I suggest you hit the bonecp forums since I'm not aware of how bonecp works to comment on this behaviour.

0

I have hit the bonecp forum and will wait for their answer. Beside that on my production server which have been running I notice there is a slight increase in the memory especially on the resident memory and I am also monitoring the perm generation which also show some small increase over few days. What does all this pattern leads to?

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.