2.0.14.3. Timeout while getting a connection from pool.

[Miłosz Kubański]

Hi.

I'm wondering whether the following message is provided only in case there is MaxPoolSize exceeded or it could also be related with a problem of getting the connection from the DB. 

Does a mechanism provided by Francisco (logging the stack trace at which connection has been opened and hasn't been closed correctly) still exists in npgsql logging mechanism? How the logger should be configured to receive this information in the newest npgsql version?

Best Regards,

MiloszeS

[Francisco Figueiredo Jr.]

On Tue, Mar 18, 2014 at 5:46 AM, Miłosz Kubański <milo...@gmail.com> wrote:

Hi.

Hi!

 

I'm wondering whether the following message is provided only in case there is MaxPoolSize exceeded or it could also be related with a problem of getting the connection from the DB. 

Only when MaxPoolSize is exceeded and a connection wasn't made available in the timeout time.

Another way to check that is to specify a value of 0 to timeout. 

According to this code:

if (Connector == null)
            {
                if (Connection.Timeout > 0)
                {
                    throw new Exception("Timeout while getting a connection from pool.");
                }
                else
                {
                    throw new Exception("Connection pool exceeds maximum size.");
                }
            }

If the timeout is 0, Npgsql won't try to wait for a connection and will throw an exception telling you that the maximum number of connections has been reached.

Does a mechanism provided by Francisco (logging the stack trace at which connection has been opened and hasn't been closed correctly) still exists in npgsql logging mechanism? How the logger should be configured to receive this information in the newest npgsql version?

Unfortunately no. :(

I left it as a side project to be incorporated in Npgsql and didn't conclude it. But based on your feedback and the other one you gave me in the past about this feature, I'll open an issue in github to add this feature to Npgsql. For while, I'd ask you to use that version of Npgsql I send you before to try to determine where those connections are being allocated so you can point out why those connections are not being released to the pool.

As soon as I get the PR up, I'll let you know.  

Sorry for this problem, Milosz. I hope next version of Npgsql has this feature implemented.

--
Regards,

Francisco Figueiredo Jr.
Npgsql Lead Developer
http://www.npgsql.org
http://gplus.to/franciscojunior
http://fxjr.blogspot.com
http://twitter.com/franciscojunior

[Francisco Figueiredo Jr.]

Hi, Milosz!

I just finished a patch for master branch which adds support for connection pool tracking.

You can have a look at it here: 
https://github.com/franciscojunior/Npgsql/commit/9143798dd93b9eba625d157eef54a5be9ccc2542

It is in the branch add-connection-pool-tracking branch: https://github.com/franciscojunior/Npgsql/commits/add-connection-pool-tracking

Please, let me know if it works OK for you. I was thinking about improving this feature by adding an NpgsqlDiagnostics class which would provide information about Npgsql internals.

Let me know if you have any ideas for improvements.

Thanks in advance! 

 

[Francisco Figueiredo Jr.]

I forgot to add that in order to get the information in your logs, you have to tell Npgsql to use a log:

NpgsqlEventLog.LogName = "NpgsqlTests.LogFile";

Just add this line of code at the start of your application and you will get stack traces which will show you where the connections in the connection pool were allocated which can help you find out why the pool is full.

I hope it helps.