Unexpected EOF on client connection

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.

Re: 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.

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.

Re: 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.
>

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.

Re: Unexpected EOF on client connection

> On Tue, Dec 1, 2009 at 7:52 AM, Howard Cole <[hidden email]> 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?

Re: Unexpected EOF on client connection

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.

Re: Unexpected EOF on client connection

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!

Re: Unexpected EOF on client connection

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 :)

Re: Unexpected EOF on client connection

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?