We use GraniteDS and server push based on APR from Tomcat native 1.1.20 in
When we connect to the server with a client flex app which sets up the comet
connection and then stop the client (e.g. stop the browser running the app)
the server's CPU utilization becomes 100%. This happens with the server
running on a Windows XP machine. The server running on Linux or Mac this
scenario works ok.
Deeper investigation reveals that this behaviour is a result of the
APR poll mechanism in APREndpoint.Poller inner class which calls the
static Poll.poll() that is implemented in the APR native code.
This polling mechanism returns with a timeout when the client is
available but not sending anything. This is all ok.
Polling from the server under Windows on a disconnected client
connection returns with a code other than timeout, but with a
different code than under Linux. From there on the behaviour under
Windows and Linux is very different. Under Linux (and I guess also
under MacOS) the polling is stopped and all threads are going into a
wait until a new client connect request comes in. Under Windows the
poll continues in a rapid loop taking all of the CPU.
Anybody with a similar experience and/or solution?