apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard van der Laan <richard.vanderl...@luminis.eu>
Subject Re: 100% cpu with APR on Windows
Date Thu, 28 Apr 2011 18:05:22 GMT
Hi Jeff,

Thanks for the reply.
I will apply the patch and see if it solves our problem.



On 28 apr. 2011, at 15:33, "Jeff Trawick" <trawick@gmail.com> wrote:

> On Thu, Apr 28, 2011 at 9:17 AM, Richard van der Laan
> <richard.vanderlaan@luminis.eu> wrote:
>> Hi,
>> We use GraniteDS and server push based on APR from Tomcat native 1.1.20 in
>> JBoss-4.2.3.
>> 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?
> This is what you need, right?  (sorry, in a rush at the moment)
> http://svn.apache.org/viewvc?view=revision&revision=1089433
> IIRC, wrowe mentioned holding off this Windows change/fix/whatever to
> 1.5.x and doc it for 1.4.x.  IMO it is okay to make the change in
> 1.4.x (i.e., it is a bug fix, not a feature, and however much it sucks
> some apps will have to depend on certain .x revisions because of bug
> fixes).

View raw message