You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Richard van der Laan <ri...@luminis.eu> on 2011/04/28 15:17:03 UTC

100% cpu with APR on Windows

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?

Regards,

Richard

Re: 100% cpu with APR on Windows

Posted by Richard van der Laan <ri...@luminis.eu>.
Hi Jeff,

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


Regards,

Richard

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

> On Thu, Apr 28, 2011 at 9:17 AM, Richard van der Laan
> <ri...@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).

Re: 100% cpu with APR on Windows

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/28/2011 9:32 AM, Jeff Trawick wrote:
> 
> 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).

If we want to view this as a bug, I'd still suggest @bug'ing the fn
declaration's doxygen that this was not consistently supported prior
to apr 1.4.3.

Re: 100% cpu with APR on Windows

Posted by Mladen Turk <mt...@apache.org>.
On 04/28/2011 03:32 PM, Jeff Trawick wrote:
> On Thu, Apr 28, 2011 at 9:17 AM, Richard van der Laan
> <ri...@luminis.eu>  wrote:
>> Hi,
>>
>> 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).
>

That shouldn't be a problem cause we build the official tcnative
with static APR so when there is a first fixed APR version we'll
release the 1.1.21 together with fixed APR.


Regards
-- 
^TM

Re: 100% cpu with APR on Windows

Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Apr 28, 2011 at 9:17 AM, Richard van der Laan
<ri...@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).