I'll try and keep this brief so in a nutshell:

I have large distributed java system running on a Windows 2003 server
(4cpu 8Gb memory).

Periodically the following exceptions occurs in the servers:

java.net.SocketException: No buffer space available (maximum
connections reached?): recv failed

I know for a fact we are not using too many TCPIP sockets or running
too many socket servers.

I have googled this error and found very little to help me.

What buffer space is this?
What does recv failed mean?

(Is it at all relevant that sql server is running on the same box?)

Any advice appreciated.
Thanks in advance.

Dan

(daniel.shaya@tamesis.com) writes:
> I'll try and keep this brief so in a nutshell:
>
> I have large distributed java system running on a Windows 2003 server
> (4cpu 8Gb memory).
>
> Periodically the following exceptions occurs in the servers:
>
> java.net.SocketException: No buffer space available (maximum
> connections reached?): recv failed
>
> I know for a fact we are not using too many TCPIP sockets or running
> too many socket servers.
>
> I have googled this error and found very little to help me.
>
> What buffer space is this?
> What does recv failed mean?
>
> (Is it at all relevant that sql server is running on the same box?)

At least I can answer the question what "recv failed". It means that a
call to recv failed. recv is one of the basic TCP/IP functions. Doing
"man recv" on a Unix box, I see

recv, recvfrom, recvmsg - receive a message from a socket

As for the buffer space, I assume that there is a shortage of
virtual memory somewhere. Maybe because you are not closing connection
correcly, or retrieving all data. Or you simply have a memory leak.
But I don't know Java, so I don't really have a clue in that part.

Whether the presence of SQL Server could matter, SQL Server by default
grabs as much memory it can, so it can as much in cache as possible. Then
again, it yields memory if another app competes for memory. You could
configure SQL Server to use less memory, but my gut feeling tells me
that you would still see this message, just less often.


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

<daniel.shaya@tamesis.com> wrote:

> I'll try and keep this brief so in a nutshell:
>
> I have large distributed java system running on a Windows 2003 server
> (4cpu 8Gb memory).
>
> Periodically the following exceptions occurs in the servers:
>
> java.net.SocketException: No buffer space available (maximum
> connections reached?): recv failed
>
> I know for a fact we are not using too many TCPIP sockets or running
> too many socket servers.
>
> I have googled this error and found very little to help me.
>
> What buffer space is this?
> What does recv failed mean?
>
> (Is it at all relevant that sql server is running on the same box?)
>
> Any advice appreciated.
> Thanks in advance.
>
> Dan

Dan,

Erland's already explained what recv is. The buffer the error message is
talking about refers to the TCP/IP stack's buffers. The error you're seeing
can be caused by multiple things: too much data queued up for send via
TCP/IP or you're out of ephemeral sockets. The big problem is that the
number of available ephmeral sockets doesn't change just because you have a
massive amount of RAM. I'm not a Winsock expert, but running out of
ephemeral sockets is common problem on Windows. Well, not that common, but
it's a fairly well known occurrence amoung the networking guru's (I'm *not*
one of those).

> (Is it at all relevant that sql server is running on the same box?)

Maybe: it definitely won't help

> I know for a fact we are not using too many TCPIP sockets or running
> too many socket servers.

Are you sure? Because it's not just how many you have open simultaneously:
if you're rapidly opening and closing sockets you could cause the problem
you're seeing... there's a timeout period before the socket you closed is
returned to the available pool. Also, I haven't worked with Java's sockets
that much: if you don't explicitly close the socket, does it stick around
until a garbage collection cycle?

Download tcpview.exe from sysinternals.com: when the problem occurs, fire it
up and see what process has the greatest number of sockets out there. If
I'm correct, you'll probably see a bunch of sockets associated with one or a
few processes (and they'll probably be in the TIME_WAIT state...)


Here's some links that may help

A discussion of ephemeral ports

http://www.tcpipguide.com/free/t_TCP...plicat io.htm

See this for some help on the Windows side (but be careful!)

http://support.microsoft.com/default...b;EN-US;196271

See this for someone with a similar problem...

http://forum.java.sun.com/thread.jsp...sageID=3177261


Craig

Thanks so much for the reply.

It is possible that sql server is the cause of the problem.

What I neglected to mention is that the system was running fine on the
machine whilst it had some VM software that partitioned the hardware
into 3 virtual boxes.

Once the VM software was removed the problem began.

Does this ring any more bells?

Can you suggest how best to set the memory limits on sql server.

Thanks again
Daniel

Just tried reduciing the max memory and problem still persists.

Getting desperate .....

(daniel.shaya@tamesis.com) writes:
> Thanks so much for the reply.
>
> It is possible that sql server is the cause of the problem.
>
> What I neglected to mention is that the system was running fine on the
> machine whilst it had some VM software that partitioned the hardware
> into 3 virtual boxes.
>
> Once the VM software was removed the problem began.
>
> Does this ring any more bells?
>
> Can you suggest how best to set the memory limits on sql server.

Enterprise Manager, Properties, the Memory tab. Here you can set min
and max memory SQL Server can use.

But I'm not surprised that if it does not help. The difference between
your current setup and your previous, is that communication to SQL
Server is really an intra-machine story, and this could affect TCP/IP.
But you don't really need TCP/IP in this. The preferred method for
communication in this case is shared memory, and unless you specify
a network library, this is what you will get in this case. Also, open
the Client Network Utility, and make sure that shared memory is available.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp