Logon fails with "lacked sufficient buffer space" message

Written on Wednesday, 04 November 2009 by Michael Vanhoutte in Engine
Tags: Adam 4.5, Adam 4.4

This article explains what's going on if you see an ADAM logon failing and you find the following error message in the event log:

SocketException:
An operation on a socket could not be performed because the system lacked
sufficient buffer space or because a queue was full 127.0.0.1:1834

When ADAM is attempting to log on for the first time in a specific Windows process, the Application object will attempt to establish a connection to the Adam Service running on that server using TCP/IP. It does that to verify licensing information, determine the database info...

To establish this TCP/IP connection, Adam will use an ephemeral port that is still available on the Windows server. The total number of ephemeral ports represent the total number of TCP/IP connections that can be made concurrently. If some other application is continuesly making TCP/IP connections to this server (for example through FTP) and is failing to properly close these connections, then you can run into the situation where you run out of available ephemeral ports.

In this case, an ADAM logon will fail with the error above. Even though ADAM is failing at this point, the root cause of this problem is not ADAM, but is the fact that Windows is running out of these ports. Find out which server and application is failing to properly close their TCP/IP connections and you'll find the cause of the problem.

Here are some tools that will help you to troubleshoot:

Use netstat -a -n to display the list of active TCP/IP connections in command line. A few hundred of these connections on a single server is perfectly reasonable. More than 5000 is a problem.
TCPView of Sysinternals also displays a list of TCP/IP connections currently active on this server. Using this tool, you can see which computer is establishing all these connections. Once you have determined which computer is causing the problems, then start TCPView on that computer as well and then double click on one of the problematic TCP/IP connections. This shows which process is initiating these connections.

Comments