It's usually set to 60 seconds.
But I think con pool will hold the connection, so is there any conflict? Thank you.
Here is the answer from Glassfish Wiki:
idle-timeout-in-seconds
maximum time in seconds, that a connection can remain idle in
the pool. After this time, the pool implementation can close
this connection. ====>Note that this does not control connection
timeouts enforced at the database server side<====. Adminsitrators
are advised to keep this timeout shorter than the EIS
connection timeout (if such timeouts are configured on the
specific EIS), to prevent accumulation of unusable connection
in Application Server.
Related
i am using Glassfish 3 & mysql5.6.11.
i have created JDBC connection pool in glassfish.
Initial and Minimum Pool Size: - 8
Maximum Pool Size: -30
Pool Resize Quantity:- 10
Idle Timeout: - 60 (second).
Max Wait Time:- 2500 (millisecond).
with this parameter i have created pool setting.
i have set pool resize quantity value.
when no of connections increase, it does not release after idle time-out.
next time when i hit url it again increase no of connection, it does not reuse already open connection.
i am getting 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.
i am using show processlist in mysql to show open connection.
if any one knows the solution of this problem, please share your idea with me.
i need help from any one.
Idle timeout is just the time that unused connections in the pool will remain in the pool before they are closed/recycled. That problem you are having is most likely that you are not closing your connections after use.
Fix your code to close connections when you are done with them, closing a connection will release it back to the connection pool so they are available for reuse.
Some connection pools have additional timeouts for the time a connection can be used, forcing the connection back in the pool after that time. Which to the user of that connection will look as if the connection has been closed. I don't think the glassfish pool has this option though.
We have over 500 processes in our service server, and each of them will keep a mysql connection to the mysql server.
If we keep over 500 connections to mysql server at the same time, is it going to affect the performance of mysql?
In my opinion, the performance won't be affect, since mysql server will keep a connection pool, and response to service server when there is a sql request.
For our situation, we will have a connection pool over 500, and I don't think 500 will be too much for mysql.
I don't know your configuration, but I know that this can be bad. If all connections are closed propper this won't be a problem, but If not it can happen that your server won't accept more connections until a timeout is reached which would result a big delay for your clients. If possible pool the connection on the client site too, this is always a good idea, so you don't need to wait that the tcp connection is established and the auth and so on.
i have web app running on GF 3.1.1 using MYSQL connection pool. When i check connections to DB using : "show processlist;" i can see everytime that only one connection is used. Why is this happening? There are a lot of threads that do something with DB. Please can someone answer my question?
Thank you very much.
You're connection pool is a pool of available connections. You might have 32 connections available but that doesn't mean it will connect them all. It will manage the connections for you. As demand increases the number of open connections will increase till your max is reached. Likewise as demand decreases your open connections will decrease down to your minimum.
Assuming your queries are fast GF is probably deciding that 1 connection is all that's needed.
Having said all that, the default min connection is 8 so log into your Admin console and look at your connection pool settings. The number of open connections should be at least what the min is set too.
In order to avoid the overhead of establishing a new connection each time a query needs fired against MySQL, there are two options available:
Persistent connections, whereby a new connection is requested a check is made to see if an 'identical' connection is already open and if so use it.
Connection pooling, whereby the client maintains a pool of connections, so that each thread that needs to use a connection will check out one from the pool and return it back to the pool when done.
So, if I have a multi-threaded server application expected to handle thousands of requests per second, and each thread needs to fire a query against the database, then what is a better option?
From my understanding, With persistent connections, all the threads in my application will try and use the same persistent connection to the database because they all are using identical connections. So it is one connection shared across multiple application threads - as a result the requests will block on the database side soon.
If I use a connection pooling mechanism, I will have all application threads share a pool of connections. So there is less possibility of a blocking request. However, with connection pooling, should an application thread wait to acquire a connection from the pool or should it send a request on the connections in the pool anyway in a round-robin manner, and let the queuing if any, happen on the database?
Having persistent connections does not imply that all threads use the same connection. It just "says" that you keep the connection open (in contradiction to open a connection each time you need one). Opening a connection is an expensive operation, so - in general - you try to avoid opening connections more often than necessary.
This is the reason why multithreaded applications often use connection pools. The pool takes care of opening and closing connections and every thread that needs a connection requests one from the pool. It is important to take care that the thread returns the connection as soon as possible to the pool, so that another thread can use it.
If your application has only a few long running threads that need connections you can also open a connection for each thread and keep this open.
Using just one connection (as you described it) is equal to a connection pool with the maximum size one. This will be sooner or later your bottleneck as all threads will have to wait for the connection. This could be an option to serialize the database operations (perform them in a certain order), although there are better options to ensure serialisation.
Update: The newer X Protocol supports asynchronous connections, and newer drivers like Node's can utilize this.
Regarding your question about should the application server wait for a connection, the answer is yes.
MySQL connections are blocking. When you issue a request from MySQL server over a connection, the connection will wait, idle, until a response is received from the server.
There is no way to send two requests on the same connection and see which returns first. You can only send one request at a time.
So, generally, a single thread in a connection pool consists of one client side connection (in your case, the application server is the client) and one server side connection (database).
Your application should wait for an available connection thread from the pool, allowing the pool to grow when it's needed, and to shrink back to your default number of threads, when it's less busy.
I recently switched from Apache DBCP connection pooling to C3P0 and have gone through my logs to see that there are connection timeout issues. I haven't had this in the past with DBCP and Tomcat, so I'm wondering if it is a configuration issue or driver issue.
Whenever I load a page after the server has been idle for a while, I'll see that some content is not sent (as the server cannot get a connection or something). When I refresh the page, all of the content is there.
Does anyone recommend using the MySQL connection pool since I'm using MySQL anyway? What are your experiences with the MySQL Connection Pool?
Walter
If the database you're working with is configured to timeout connections after a certain time of inactivity, they are already closed and thus unusable when they are borrowed from the pool.
If you cannot or do not want to reconfigure your database server, you can configure C3P0 (and most other connection pools) to test the connections with a test query when they are borrowed from the pool. You can find more detailed information in the relevant section of the C3P0 documentation.
Edit: Of course you're right, it's also possible that there was a maximum idle time configured in the DBCP pool, causing them to be removed from the pool before they would time out. Anyway, using either a test query or making sure the connections are removed from the pool before they time out should fix the problem.
Just adding a link to another connection pool; BoneCP (http://jolbox.com); the connection pool that is faster than both C3P0 as well as DBCP.
Like C3P0 and DBCP, make sure you configure idle connection testing to avoid the scenario you described (probably MySQL's wait_timeout setting is kicking in, normally set to 8 hours).