Hanging on ServerSocket.accept()

[Paul J. Lucas]

I'm using Restlet and the Simple web server. When launching my application,
perhaps 1/10 times, the web server gets stuck in ServerSocket.accept(). This
means a client establishes a connection then both it and the server just sit there.

This happens only when run under Windows and only for one of our users. (The
user had turned off all firewall and virus software.) The thing that concerns
me is how wide-spread the problem is. (Our product is not yet released.) The
problem has never been observed to happen under Mac OS X.

Note that I said it *hangs* on *accept*. Therefore, this has nothing to do with
the SO_LINGER socket option. The server binds to and listens on the socket just
fine.

I tried replacing Simple with Jetty, but the same thing happens, so that
probably rules out both as having anything to do with the cause. I also doubt
that it has anything to do with Restlet since that's an even higher layer that
sits on top of the web server.

Has anybody else experienced something like this or have any suggestions?

- Paul

 

[Nigel Wade]

I'm using Restlet and the Simple web server. When launching my application,
perhaps 1/10 times, the web server gets stuck in ServerSocket.accept(). This
means a client establishes a connection then both it and the server just sit there.

This happens only when run under Windows and only for one of our users. (The
user had turned off all firewall and virus software.) The thing that concerns
me is how wide-spread the problem is. (Our product is not yet released.) The
problem has never been observed to happen under Mac OS X.

Note that I said it *hangs* on *accept*. Therefore, this has nothing to do with
the SO_LINGER socket option. The server binds to and listens on the socket just
fine.

I tried replacing Simple with Jetty, but the same thing happens, so that
probably rules out both as having anything to do with the cause. I also doubt
that it has anything to do with Restlet since that's an even higher layer that
sits on top of the web server.

Has anybody else experienced something like this or have any suggestions?

- Paul

Have you checked how many TCP/IP connections are currently in use? Netstat can
tell you. It might be the current OS limit on sockets has been reached and the
new socket can't be established until at least one existing socket fully
closes.

As I understand it desktop versions of Windows are severely (and deliberately)
limited in this respect. That may be why you only see the problem on Windows.

 

[Paul J. Lucas]

Have you checked how many TCP/IP connections are currently in use?

No, but the machine is otherwise idle. I really doubt it's that since the user
uses all manner of other software with no difficultly.

Netstat can
tell you. It might be the current OS limit on sockets has been reached and the
new socket can't be established until at least one existing socket fully
closes.

And how do I know what the limit is and whether it's been reached?

- Paul

 

[Nigel Wade]

No, but the machine is otherwise idle. I really doubt it's that since the user
uses all manner of other software with no difficultly.

But if your application is creating lots of sockets it wouldn't matter what else
the system was doing.

And how do I know what the limit is and whether it's been reached?

I don't know what the limit is, I only have empirical evidence from trying to
solve a problem I once had. I seem to remember reading that the Windows desktop
editions can only connect to 4 different hosts simultaneously. I've not tested
this as this wasn't my problem.

The problem I had was that Windows wasn't actually closing the sockets
immediately. My client application was creating and destroying thousands of
sockets in a few seconds. At some point the application was unable to create
any new Sockets. Looking at netstat it was clear that even though the sockets
had been closed by the application, and as far as it was concerned they were
closed, they were still hanging around. From observation it looked as though
Windows only got around to clearing the sockets every 20-30s, maybe on a timer.
So, after the application had closed the sockets they'd all hang around until,
every 20s or so, Windows got around to actually closing them. A whole bunch
would then disappear allowing the application to open new ones.

It's a while since I had this problem so I'm not certain, but I think the client
didn't hang, I actually got IOExceptions in the client, so this may not be your
problem. I only put it forward as a suggestion since it's easy to check using
netstat.

 

[Paul J. Lucas]

I don't know what the limit is, I only have empirical evidence from trying to
solve a problem I once had. I seem to remember reading that the Windows desktop
editions can only connect to 4 different hosts simultaneously. I've not tested
this as this wasn't my problem.

The problem I had was that Windows wasn't actually closing the sockets
immediately. My client application was creating and destroying thousands of
sockets in a few seconds.

But my application works just fine some of the time. If it were reaching some
limit, you'd think it would do it every time the application was run.

- Paul

 

[EJP]

But my application works just fine some of the time. If it were
reaching some limit, you'd think it would do it every time the
application was run.

The problem he had was with outgoing connections and the FIN_WAIT_2
state and too many ports being used in too short a time, which is a
consequence of too many outbound connections. Nothing to do with your
problem which is about *accepting* connections.