Re: SocketException on connect, busy server

Hi!

Thanks for your reply, and sorry for my late rereply!

I should of course have mentioned that we use FreeBSD-4.3.

I doubt we open postgres connections at that rate, but quite
possibly HTTP and other protocols, but that is different ports.
Postgres connections are pooled, and we don't even allow 268
connections, so...

I don't really think there is problem with the TCP
implementation in FreeBSD, but maybe I can tweak som
parameters. I'll read about the stuff and see what I can come
up with. Any ideas are welcome.

Thanks!

/Palle

Rene Pijlman wrote:
>
> On Sun, 02 Sep 2001 23:41:49 +0200, you wrote:
> >On a busy server, serving web pages using tomcat and apache, I
> >get this error sometimes:
> >
> >java.net.SocketException: errno: 48, error: Address already in
> >use for fd: 168
> >        at java.net.PlainSocketImpl.socketConnect(Native
> >Method)
>
> This means the underlying connect(2) socket call returns errno
> EADDRINUSE.
>
> On a connect(), this means that the 5-tuple <protocol,local
> address,local port,remote address,remote port>
> would not be unique if the operation had been allowed. Since
> protocol, local address, remote address and remote port are
> fixed, this occurs if the local socket implementation cannot
> provide a local port number that is still available with respect
> to the 4 fixed parts. The port number is a 16 bit number, ports
> 0-1024 are usually not available as dynamically allocated,
> leaving 64511 ports available. TCP defines a 4 minute TIME_WAIT
> state, so there can be no more than 64511 / 4 * 60 = 268
> connections per second from a single client IP address to one
> particular service.
>
> This is usually only a problem with load balancing HTTP servers
> and other stateless protocols, not with database servers, since
> database connections are typically pooled. Is your application
> opening and closing PostgreSQL connections at such a high rate?
>
> In any case, you should probably attack this problem at the TCP
> implementation level of your OS. It is most likely not
> PostgreSQL specific.
>
> Google gives some interesting hits:
> http://www.google.com/search?q=time%5Fwait
>
> Regards,
> René Pijlman <rene@lab.applinet.nl>

--
         Partitur Informationsteknik AB
Wenner-Gren Center             +46 8 566 280 02
113 46 Stockholm           +46 70 785 86 02
Sweden                   girgen@partitur.se