Обсуждение: Unexpected EOF on client connection
I am getting many entries in my log of this type: 2009-12-01 00:13:19 GMTLOG: unexpected EOF on client connection 2009-12-01 00:13:19 GMTLOG could not receive data from client: No connection could be made because the target machine actively refused it. I tend to get these message in batches of 2 to 8 - checking the number of connections at the time, they do not appear to be overloaded. I am running 8.4.1 on Windows 2K3 with a C# application using Npgsql. All connections are to the localhost and there is no firewall. Help! Howard Cole www.selestial.com
On Tue, Dec 1, 2009 at 7:52 AM, Howard Cole <howardnews@selestial.com> wrote: > I am getting many entries in my log of this type: > > 2009-12-01 00:13:19 GMTLOG: unexpected EOF on client connection > 2009-12-01 00:13:19 GMTLOG could not receive data from client: No connection > could be made because the target machine actively refused it. > > I tend to get these message in batches of 2 to 8 - checking the number of > connections at the time, they do not appear to be overloaded. > > I am running 8.4.1 on Windows 2K3 with a C# application using Npgsql. All > connections are to the localhost and there is no firewall. I'm going to make a guess that your client application is not explicitly closing the C# connection objects before the objects go out of scope. Once the object become eligible for the garbage collector, its destroyed and then Postgres notices that it can talk to the client anymore. Hence you get the above mentioned error. -- Regards, Richard Broersma Jr. Visit the Los Angeles PostgreSQL Users Group (LAPUG) http://pugs.postgresql.org/lapug
On Tue, Dec 1, 2009 at 13:52, Howard Cole <howardnews@selestial.com> wrote: > I am getting many entries in my log of this type: > > 2009-12-01 00:13:19 GMTLOG: unexpected EOF on client connection > 2009-12-01 00:13:19 GMTLOG could not receive data from client: No connection > could be made because the target machine actively refused it. > > I tend to get these message in batches of 2 to 8 - checking the number of > connections at the time, they do not appear to be overloaded. > > I am running 8.4.1 on Windows 2K3 with a C# application using Npgsql. All > connections are to the localhost and there is no firewall. > Maybe this is Npgsql removing connections from pool after some time. But it may not be this case because Npgsql finishes the connection correctly when removing it from the pool. You can confirm that by playing with your max connection pool and min connection pool values in your connection string. Try to put a higher value of min connection pool, so they aren't closed too frequently. Also, as Richard said, check your connection usage pattern in your application. I hope it helps. -- Regards, Francisco Figueiredo Jr. Npgsql Lead Developer http://www.npgsql.org http://fxjr.blogspot.com http://twitter.com/franciscojunior
Richard Broersma wrote: > On Tue, Dec 1, 2009 at 7:52 AM, Howard Cole <howardnews@selestial.com> wrote: > >> I am getting many entries in my log of this type: >> >> 2009-12-01 00:13:19 GMTLOG: unexpected EOF on client connection >> 2009-12-01 00:13:19 GMTLOG could not receive data from client: No connection >> could be made because the target machine actively refused it. >> >> I tend to get these message in batches of 2 to 8 - checking the number of >> connections at the time, they do not appear to be overloaded. >> >> I am running 8.4.1 on Windows 2K3 with a C# application using Npgsql. All >> connections are to the localhost and there is no firewall. >> > > I'm going to make a guess that your client application is not > explicitly closing the C# connection objects before the objects go out > of scope. Once the object become eligible for the garbage collector, > its destroyed and then Postgres notices that it can talk to the client > anymore. Hence you get the above mentioned error. > > I am quite thorough and keep database access restricted to a single class with strict exception handling to catch errors. And force the connection to close / force disposal everywhere. But I shall certainly be checking my code - thanks for the tip. Interesting what Francis says about the pool connections being closed before disposal. Presumably I should never get this error if I use Npgsql?
Howard Cole wrote: > > Interesting what Francis says about the pool connections being closed > before disposal. Apologies "Francisco" > Presumably I should never get this error if I use Npgsql? >
On Tue, Dec 1, 2009 at 21:39, Howard Cole <howardnews@selestial.com> wrote: > Howard Cole wrote: >> >> Interesting what Francis says about the pool connections being closed >> before disposal. > > Apologies "Francisco" >> :) No problem. >> Presumably I should never get this error if I use Npgsql? >> That's correct. But there may be a bug in Npgsql code itself. That's why I asked you to try to raise minpoolvalue to check if you see less errors. I hope it helps. -- Regards, Francisco Figueiredo Jr. Npgsql Lead Developer http://www.npgsql.org http://fxjr.blogspot.com http://twitter.com/franciscojunior
Francisco Figueiredo Jr. wrote: >>> Presumably I should never get this error if I use Npgsql? >>> >>> > > That's correct. But there may be a bug in Npgsql code itself. > That's why I asked you to try to raise minpoolvalue to check if you > see less errors. > > I hope it helps. > > > Thanks Francisco - I currently have MinPoolSize set to 3 (I have a lot of databases on this cluster), I think this copes 90% of the time but I shall set it to 10 and see what happens.
Howard Cole wrote: > Thanks Francisco - I currently have MinPoolSize set to 3 (I have a lot > of databases on this cluster), I think this copes 90% of the time but > I shall set it to 10 and see what happens. > Sampling the number of connections on my database I decided that the number of connections settled at 6 so I changed my MinPoolSize from 3 to 6. I checked the current state of the database and the number of connections is currently 12. Tonight I shall change the MinPoolSize to 8 and I am wondering if the number of connections used is going to appear as 16!
Howard Cole wrote: > Howard Cole wrote: >> Thanks Francisco - I currently have MinPoolSize set to 3 (I have a >> lot of databases on this cluster), I think this copes 90% of the time >> but I shall set it to 10 and see what happens. >> > Sampling the number of connections on my database I decided that the > number of connections settled at 6 so I changed my MinPoolSize from 3 > to 6. I checked the current state of the database and the number of > connections is currently 12. Tonight I shall change the MinPoolSize to > 8 and I am wondering if the number of connections used is going to > appear as 16! > Pretty soon you'll discover that you have two instances of the pool :)
David Boreham wrote: >> Sampling the number of connections on my database I decided that the >> number of connections settled at 6 so I changed my MinPoolSize from 3 >> to 6. I checked the current state of the database and the number of >> connections is currently 12. Tonight I shall change the MinPoolSize >> to 8 and I am wondering if the number of connections used is going to >> appear as 16! >> > Pretty soon you'll discover that you have two instances of the pool :) > lol. Changed the MinPoolSize and the number of connections is exactly the pool size at the moment. So no doubling up this time. The npgsql pooling appears to be working as expected. The errors are still appearing in the log. What happens to new connections that exceed the pool size? Are the connections added to the pool briefly, or are they created outside the pool and allowed to timeout on their own? Also are the pooled connections set to renew if they timeout, or do they never timeout?