Fwd: Re: 100% cpu with APR on Windows
Hi,
Maybe the patch is required as an attachment? Here it is.
Can it be included in apr?
Regards,
Eric
--- apr.orig/poll/unix/select.c 2009-10-02 18:24:00.0 +0200
+++ apr/poll/unix/select.c 2011-07-07 14:55:29.0 +0200
@@ -149,6 +149,14 @@
break;
}
if (FD_ISSET(fd, &readset)) {
+char c;
+int r = recv(fd, &c, 1, MSG_PEEK);
+if (r == 0) {
+aprset[i].rtnevents |= APR_POLLHUP;
+}
+else if (r < 0) {
+aprset[i].rtnevents |= APR_POLLERR;
+}
aprset[i].rtnevents |= APR_POLLIN;
}
if (FD_ISSET(fd, &writeset)) {
@@ -399,6 +407,14 @@
pollset->p->result_set[j] = pollset->p->query_set[i];
pollset->p->result_set[j].rtnevents = 0;
if (FD_ISSET(fd, &readset)) {
+char c;
+int r = recv(fd, &c, 1, MSG_PEEK);
+if (r == 0) {
+pollset->p->result_set[j].rtnevents |= APR_POLLHUP;
+}
+else if (r < 0) {
+pollset->p->result_set[j].rtnevents |= APR_POLLERR;
+}
pollset->p->result_set[j].rtnevents |= APR_POLLIN;
}
if (FD_ISSET(fd, &writeset)) {
--
---
| Eric van der Maarel |
| NEDAP IDEAS |
| eric.vandermaa...@nedap.com |
---^[ZZ
--- apr.orig/poll/unix/select.c 2009-10-02 18:24:00.0 +0200
+++ apr/poll/unix/select.c 2011-07-07 14:55:29.0 +0200
@@ -149,6 +149,14 @@
break;
}
if (FD_ISSET(fd, &readset)) {
+char c;
+int r = recv(fd, &c, 1, MSG_PEEK);
+if (r == 0) {
+aprset[i].rtnevents |= APR_POLLHUP;
+}
+else if (r < 0) {
+aprset[i].rtnevents |= APR_POLLERR;
+}
aprset[i].rtnevents |= APR_POLLIN;
}
if (FD_ISSET(fd, &writeset)) {
@@ -399,6 +407,14 @@
pollset->p->result_set[j] = pollset->p->query_set[i];
pollset->p->result_set[j].rtnevents = 0;
if (FD_ISSET(fd, &readset)) {
+char c;
+int r = recv(fd, &c, 1, MSG_PEEK);
+if (r == 0) {
+pollset->p->result_set[j].rtnevents |= APR_POLLHUP;
+}
+else if (r < 0) {
+pollset->p->result_set[j].rtnevents |= APR_POLLERR;
+}
pollset->p->result_set[j].rtnevents |= APR_POLLIN;
}
if (FD_ISSET(fd, &writeset)) {
Re: 100% cpu with APR on Windows
On 07/06/2011 03:58 PM, Mladen Turk wrote:
On 07/06/2011 02:52 PM, Eric van der Maarel wrote:
Hi,
Recently I proposed a fix for the select version of apr_pollset_poll
implementation, that prevents cpu going to 100% when all clients have
disconnected
(http://mail-archives.apache.org/mod_mbox/apr-dev/201106.mbox/browser). It
actually provides the select impl. of poll with the ability to issue
APR_POLLHUPP return events.
Jeff, could you please have a look at it and post any remarks you might
have.
If Jeff can't, I can ;)
Ok. Just thought it'd be more Jeff's cup of tea. Thanks.
1. One byte is enough; eg. recv(s,&c, 1, MSG_PEEK)
sure
2. Not sure that other platforms *always* set POLLHUP for
half closed sockets.
It doesn't always set POLLHUP. When socket is in accepted state,
select() keeps it in the read set and reading with recv() returns 0
graceful disconnect, possibly sudden disconnect) then POLLHUP is set.
Seems appropriate to me. When recv() result <0 POLLERR flag is set.
Part of my concern is recv() can return 0 when a socket is ready for
accept(). We just cannot detect this situation proper. My assumption is
here that it cannot happen with sockets in the poller: they are in
accept()-ed state already.
3. Missing an actual .diff -u file
added
How do I get about to get a patch like this adopted in the apr source?
Create a proper patch. It can be a while until someone
does your homework :)
the diff enough?
Thanks,
Eric
Regards
diff -u select.c.orig select.c
--- select.c.orig 2009-10-02 18:24:00.0 +0200
+++ select.c2011-07-07 14:55:29.0 +0200
@@ -149,6 +149,14 @@
break;
}
if (FD_ISSET(fd, &readset)) {
+char c;
+int r = recv(fd, &c, 1, MSG_PEEK);
+if (r == 0) {
+aprset[i].rtnevents |= APR_POLLHUP;
+}
+else if (r < 0) {
+aprset[i].rtnevents |= APR_POLLERR;
+}
aprset[i].rtnevents |= APR_POLLIN;
}
if (FD_ISSET(fd, &writeset)) {
@@ -399,6 +407,14 @@
pollset->p->result_set[j] = pollset->p->query_set[i];
pollset->p->result_set[j].rtnevents = 0;
if (FD_ISSET(fd, &readset)) {
+char c;
+int r = recv(fd, &c, 1, MSG_PEEK);
+if (r == 0) {
+pollset->p->result_set[j].rtnevents |= APR_POLLHUP;
+}
+else if (r < 0) {
+pollset->p->result_set[j].rtnevents |= APR_POLLERR;
+}
pollset->p->result_set[j].rtnevents |= APR_POLLIN;
}
if (FD_ISSET(fd, &writeset)) {
--
---
| Eric van der Maarel |
| NEDAP IDEAS |
| eric.vandermaa...@nedap.com |
---^[ZZ
Re: 100% cpu with APR on Windows
On 07/06/2011 02:52 PM, Eric van der Maarel wrote: Hi, Recently I proposed a fix for the select version of apr_pollset_poll implementation, that prevents cpu going to 100% when all clients have disconnected (http://mail-archives.apache.org/mod_mbox/apr-dev/201106.mbox/browser). It actually provides the select impl. of poll with the ability to issue APR_POLLHUPP return events. Jeff, could you please have a look at it and post any remarks you might have. If Jeff can't, I can ;) 1. One byte is enough; eg. recv(s, &c, 1, MSG_PEEK) 2. Not sure that other platforms *always* set POLLHUP for half closed sockets. 3. Missing an actual .diff -u file How do I get about to get a patch like this adopted in the apr source? Create a proper patch. It can be a while until someone does your homework :) Regards -- ^TM
Re: 100% cpu with APR on Windows
Hi, Recently I proposed a fix for the select version of apr_pollset_poll implementation, that prevents cpu going to 100% when all clients have disconnected (http://mail-archives.apache.org/mod_mbox/apr-dev/201106.mbox/browser). It actually provides the select impl. of poll with the ability to issue APR_POLLHUPP return events. Jeff, could you please have a look at it and post any remarks you might have. How do I get about to get a patch like this adopted in the apr source? Regards, Eric -- --- | Eric van der Maarel | | NEDAP IDEAS | | eric.vandermaa...@nedap.com | ---^[ZZ
Re: 100% cpu with APR on Windows
On 05/29/2011 10:53 PM, Jeff Trawick wrote:
On Fri, May 27, 2011 at 3:59 PM, Justin Erenkrantz
wrote:
On Fri, May 27, 2011 at 9:48 AM, wrote:
Can you outline the idioms you refer to that prefer a select()
implementation?
iow, how different are they from
apr_socket_create
set socket nonblocking with no timeout
apr_socket_connect()
apr_pollset_poll()
That's all serf is doing. With WSAPoll(), if you connect to a port
via a non-blocking socket that there is no listener on, WSAPoll()
never sends any indication. However, select() lets you know that the
earlier connect() failed. Given the pretty isolated test case in the
forum earlier, I do think this is an underlying issue with WSAPoll() -
but enough of an issue, it shouldn't be the default unless someone can
find a way to get WSAPoll() to report failure... -- justin
no-can-do AFAICT; there's literally NOTHING you can put in .events
which results in anything reported in .revents after ECONNREFUSED
your two cases are the only reports of WSAPoll() problems I know of in
the last year (since 1.4.x was released, making WSAPoll() the
default); still, it seems probable that more code works with a
select()-based implementation
a new WSAEVENT-based implementation may be the long term solution
(FD_CONNECT events would have to be mapped to something the app would
ask for; presumably FD_CLOSE events would map to POLLHUP, which was
the select() issue which started this thread)
I propose a patch for impl_pollset_poll() in select.c (the poller impl
based on select(), used on Windows XP).
The idea is to test all sockets that are kept by select() in the read
set, for data with a peeking recv() call. When the call to recv() for a
socket returns 0, no data read, we set the APR_POLLHUP flag in the
return event of the pollset result_set. And we set the APR_POLLERR flag
when result < 0.
This works since the socket was kept in the read set by select(), either
since there's data or since the socket was disconnected.
I'm not sure about the conditions under which recv() can return 0
though... (e.g. socket has not yet accept()ed an incoming connection
request? or data is available but for some reason recv() still reads no
data and returns 0?).
Test results so far are positive.
Here's the proposed code, with changes/additions in lines 6-12:
1 if (FD_ISSET(fd, &readset) || FD_ISSET(fd, &writeset) ||
2 FD_ISSET(fd, &exceptset)) {
3 pollset->p->result_set[j] = pollset->p->query_set[i];
4 pollset->p->result_set[j].rtnevents = 0;
5 if (FD_ISSET(fd, &readset)) {
6 r = recv(fd, buf, 8, MSG_PEEK); // 8 byte buffer
7 if (r == 0) {
8 pollset->p->result_set[j].rtnevents |= APR_POLLHUP;
9 }
10 else if (r < 0) {
11 pollset->p->result_set[j].rtnevents |= APR_POLLERR;
12 }
13 pollset->p->result_set[j].rtnevents |= APR_POLLIN;
14 }
15 if (FD_ISSET(fd, &writeset)) {
16 pollset->p->result_set[j].rtnevents |= APR_POLLOUT;
17 }
18 if (FD_ISSET(fd, &exceptset)) {
19 pollset->p->result_set[j].rtnevents |= APR_POLLERR;
20 }
21 j++;
Regards,
Eric
--
---
| Eric van der Maarel |
| NEDAP IDEAS |
| eric.vandermaa...@nedap.com |
---^[ZZ
Re: Re: 100% cpu with APR on Windows
On Fri, May 27, 2011 at 3:59 PM, Justin Erenkrantz wrote: > On Fri, May 27, 2011 at 9:48 AM, wrote: >> Can you outline the idioms you refer to that prefer a select() >> implementation? >> >> iow, how different are they from >> >> apr_socket_create >> set socket nonblocking with no timeout >> apr_socket_connect() >> apr_pollset_poll() > > That's all serf is doing. With WSAPoll(), if you connect to a port > via a non-blocking socket that there is no listener on, WSAPoll() > never sends any indication. However, select() lets you know that the > earlier connect() failed. Given the pretty isolated test case in the > forum earlier, I do think this is an underlying issue with WSAPoll() - > but enough of an issue, it shouldn't be the default unless someone can > find a way to get WSAPoll() to report failure... -- justin no-can-do AFAICT; there's literally NOTHING you can put in .events which results in anything reported in .revents after ECONNREFUSED your two cases are the only reports of WSAPoll() problems I know of in the last year (since 1.4.x was released, making WSAPoll() the default); still, it seems probable that more code works with a select()-based implementation a new WSAEVENT-based implementation may be the long term solution (FD_CONNECT events would have to be mapped to something the app would ask for; presumably FD_CLOSE events would map to POLLHUP, which was the select() issue which started this thread)
Re: Re: 100% cpu with APR on Windows
On Fri, May 27, 2011 at 9:48 AM, wrote: > Can you outline the idioms you refer to that prefer a select() > implementation? > > iow, how different are they from > > apr_socket_create > set socket nonblocking with no timeout > apr_socket_connect() > apr_pollset_poll() That's all serf is doing. With WSAPoll(), if you connect to a port via a non-blocking socket that there is no listener on, WSAPoll() never sends any indication. However, select() lets you know that the earlier connect() failed. Given the pretty isolated test case in the forum earlier, I do think this is an underlying issue with WSAPoll() - but enough of an issue, it shouldn't be the default unless someone can find a way to get WSAPoll() to report failure... -- justin
Re: Re: 100% cpu with APR on Windows
On , Justin Erenkrantz wrote: On Thu, May 26, 2011 at 10:30 PM, Justin Erenkrantz jus...@erenkrantz.com> wrote: > Has anyone else seen this behavior? Anybody have any clever > workarounds? -- justin Using apr_pollset_create_ex() with APR_POLLSET_SELECT allows serf to be happy on Win32. Besides connect() failing, there is at least one other failure due to WSAPoll [1] - I'm not terribly sure that this should be the default given how sketchy this API appears to be. Thoughts? I don't really want to put an #ifdef Win32 to avoid using the default in serf...but...well... -- justin 1. http://code.google.com/p/serf/issues/detail?id=74 Can you outline the idioms you refer to that prefer a select() implementation? iow, how different are they from apr_socket_create set socket nonblocking with no timeout apr_socket_connect() apr_pollset_poll() ?
Re: 100% cpu with APR on Windows
On Thu, May 26, 2011 at 10:30 PM, Justin Erenkrantz wrote: > Has anyone else seen this behavior? Anybody have any clever > workarounds? -- justin Using apr_pollset_create_ex() with APR_POLLSET_SELECT allows serf to be happy on Win32. Besides connect() failing, there is at least one other failure due to WSAPoll [1] - I'm not terribly sure that this should be the default given how sketchy this API appears to be. Thoughts? I don't really want to put an #ifdef Win32 to avoid using the default in serf...but...well... -- justin 1. http://code.google.com/p/serf/issues/detail?id=74
Re: 100% cpu with APR on Windows
On Fri, May 6, 2011 at 4:01 AM, Jeff Trawick wrote: > WSAPoll() is available with Vista/2008 Server and later. It should be > used automatically by APR without rebuilding your code (via a run-time > check for presence of the Windows API). > > As far as WSAPoll() and this issue... MS doc says > > "POLLHUP A stream-oriented connection was either disconnected or > aborted." > > POLLHUP is mapped to APR_POLLHUP. > > (IOW, I didn't test but it looks promising.) FWIW, serf is running into a similar issue when a connection is made to a server on a non-existent port. (The Subversion folks have marked this as a blocking bug for 1.7.x.) It looks like WSAPoll() may not work properly with non-blocking connect() calls: http://social.msdn.microsoft.com/Forums/en/wsk/thread/18769abd-fca0-4d3c-9884-1a38ce27ae90 The apr_pollset_poll call never indicates a failure (so it only returns after the timeout expires and says nothing interesting happened). Reading the connect() docs, it appears that you have to call select() - not WSAPoll() - to figure out the status of the connect() call: http://msdn.microsoft.com/en-us/library/ms737625(v=VS.85).aspx Has anyone else seen this behavior? Anybody have any clever workarounds? -- justin
Re: 100% cpu with APR on Windows
On Fri, May 6, 2011 at 4:28 AM, Eric van der Maarel wrote: > On 05/05/2011 10:17 PM, Jeff Trawick wrote: >> >> On Thu, May 5, 2011 at 3:20 PM, Eric van der Maarel >> wrote: >>> >>> Hi, >>> >>> Further investigation reveals a difference between running Tomcat on >>> Linux and Windows. From the Tomcat Poller thread the apr_pollset_poll() >>> is called. When a client in the pollset has disconnected, under Linux >>> this call returns (in the rtnevents member of the descriptors resultset) >>> 49 (=0x31, so that would be APR_POLLIN | APR_POLLERR | APR_POLLHUP), >>> while under Windows this always return >>> 1 (so APR_POLLIN) >>> >>> The poller in Tomcat reacts on the APR_POLLHUP result, so differently on >>> Windows than on Linux. I think the problem lies in the missing >>> APR_POLLHUP in the poll return result under Windows (from the >>> impl_pollset_poll implemented in select.c by the way). >>> >>> Anyone any idea why on Windows (select.c) the rtnevents does not have >>> the APR_POLLHUP flag up, while on Linux (no idea which poll provider >>> version is used ther :-) this flag is set when the client has >>> disconnected? >>> And how to fix? :-) >> >> select() has a simpler view of things; normally something needs to >> read from the readable socket, get connreset or equiv, and handle >> closed connection at that point >> >> select() on any platform can't set APR_POLLHUP as a return event >> >> maybe getsockopt(SOL_SOCKET/SO_ERROR) when socket is readable and >> APR_POLLHUP was requested would give the necessary info > > Change the apr client you mean to handle receiving APR_POLLIN, right? > > > > >> >> --/-- >> >> are you sure select() is being used? newer Windows should have >> WSApoll()? > > Yes, select() is being used (added some logging to select.c that actually > shows up). We're running on Windows XP (SP3) which, as I understand it, > doesn't have WSAPoll(). > If XP does have WSAPoll(), how to enforce it? Is it determined buildtime or > runtime which poll/pollset provider is going to be used? > Can and should we use another provider than select on XP and how can that be > configured? Or, for this use case, shouldn't we use XP altogether and use > one of those server versions of Windows instead? XP only has select() available. WSAPoll() is available with Vista/2008 Server and later. It should be used automatically by APR without rebuilding your code (via a run-time check for presence of the Windows API). As far as WSAPoll() and this issue... MS doc says "POLLHUPA stream-oriented connection was either disconnected or aborted." POLLHUP is mapped to APR_POLLHUP. (IOW, I didn't test but it looks promising.)
Re: 100% cpu with APR on Windows
On 05/05/2011 10:17 PM, Jeff Trawick wrote: On Thu, May 5, 2011 at 3:20 PM, Eric van der Maarel wrote: Hi, Further investigation reveals a difference between running Tomcat on Linux and Windows. From the Tomcat Poller thread the apr_pollset_poll() is called. When a client in the pollset has disconnected, under Linux this call returns (in the rtnevents member of the descriptors resultset) 49 (=0x31, so that would be APR_POLLIN | APR_POLLERR | APR_POLLHUP), while under Windows this always return 1 (so APR_POLLIN) The poller in Tomcat reacts on the APR_POLLHUP result, so differently on Windows than on Linux. I think the problem lies in the missing APR_POLLHUP in the poll return result under Windows (from the impl_pollset_poll implemented in select.c by the way). Anyone any idea why on Windows (select.c) the rtnevents does not have the APR_POLLHUP flag up, while on Linux (no idea which poll provider version is used ther :-) this flag is set when the client has disconnected? And how to fix? :-) select() has a simpler view of things; normally something needs to read from the readable socket, get connreset or equiv, and handle closed connection at that point select() on any platform can't set APR_POLLHUP as a return event maybe getsockopt(SOL_SOCKET/SO_ERROR) when socket is readable and APR_POLLHUP was requested would give the necessary info Change the apr client you mean to handle receiving APR_POLLIN, right? --/-- are you sure select() is being used? newer Windows should have WSApoll()? Yes, select() is being used (added some logging to select.c that actually shows up). We're running on Windows XP (SP3) which, as I understand it, doesn't have WSAPoll(). If XP does have WSAPoll(), how to enforce it? Is it determined buildtime or runtime which poll/pollset provider is going to be used? Can and should we use another provider than select on XP and how can that be configured? Or, for this use case, shouldn't we use XP altogether and use one of those server versions of Windows instead? Eric -- --- | Eric van der Maarel | | NEDAP IDEAS | | eric.vandermaa...@nedap.com | ---^[ZZ
Re: 100% cpu with APR on Windows
On Thu, May 5, 2011 at 3:20 PM, Eric van der Maarel wrote: > Hi, > > Further investigation reveals a difference between running Tomcat on > Linux and Windows. From the Tomcat Poller thread the apr_pollset_poll() > is called. When a client in the pollset has disconnected, under Linux > this call returns (in the rtnevents member of the descriptors resultset) > 49 (=0x31, so that would be APR_POLLIN | APR_POLLERR | APR_POLLHUP), > while under Windows this always return > 1 (so APR_POLLIN) > > The poller in Tomcat reacts on the APR_POLLHUP result, so differently on > Windows than on Linux. I think the problem lies in the missing > APR_POLLHUP in the poll return result under Windows (from the > impl_pollset_poll implemented in select.c by the way). > > Anyone any idea why on Windows (select.c) the rtnevents does not have > the APR_POLLHUP flag up, while on Linux (no idea which poll provider > version is used ther :-) this flag is set when the client has disconnected? > And how to fix? :-) select() has a simpler view of things; normally something needs to read from the readable socket, get connreset or equiv, and handle closed connection at that point select() on any platform can't set APR_POLLHUP as a return event maybe getsockopt(SOL_SOCKET/SO_ERROR) when socket is readable and APR_POLLHUP was requested would give the necessary info --/-- are you sure select() is being used? newer Windows should have WSApoll()?
Re: 100% cpu with APR on Windows
Hi, Further investigation reveals a difference between running Tomcat on Linux and Windows. From the Tomcat Poller thread the apr_pollset_poll() is called. When a client in the pollset has disconnected, under Linux this call returns (in the rtnevents member of the descriptors resultset) 49 (=0x31, so that would be APR_POLLIN | APR_POLLERR | APR_POLLHUP), while under Windows this always return 1 (so APR_POLLIN) The poller in Tomcat reacts on the APR_POLLHUP result, so differently on Windows than on Linux. I think the problem lies in the missing APR_POLLHUP in the poll return result under Windows (from the impl_pollset_poll implemented in select.c by the way). Anyone any idea why on Windows (select.c) the rtnevents does not have the APR_POLLHUP flag up, while on Linux (no idea which poll provider version is used ther :-) this flag is set when the client has disconnected? And how to fix? :-) Eric -- --- | Eric van der Maarel | | NEDAP IDEAS | | eric.vandermaa...@nedap.com | ---^[ZZ
Re: 100% cpu with APR on Windows
Hi, I'm in a team with Richard. We already noticed that Stefan Ruppert's original patch didn't do the trick. We've also applied the other diffs from rev. 1089433, to no avail. It seems we are not in the situation that 1089433 fixes. When we encounter the problem, we never have num == 0 or pollset->nelts == 0 (in select.c). From the differences between running the server on Linux and on Windows, I think the problem is in how the poll result is handled in the tomcat-native java class org.apache.tomcat.util.net.AprEndpoint.Poller. I could go into more detail, but: The problem we encounter is a result of interaction between APR and the java code from tomcat native (most notably org.apache.tomcat.util.net.AprEndpoint.Poller in 'comet' mode). I see Mladen Turk is also on this list; do you think we should take this issue there (too) Mladen? Regards, Eric -- --- | Eric van der Maarel | | NEDAP IDEAS | | eric.vandermaa...@nedap.com | ---^[ZZ
Re: 100% cpu with APR on Windows
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" wrote: > On Thu, Apr 28, 2011 at 9:17 AM, Richard van der Laan > 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
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
On 04/28/2011 03:32 PM, Jeff Trawick wrote: On Thu, Apr 28, 2011 at 9:17 AM, Richard van der Laan 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
On Thu, Apr 28, 2011 at 9:17 AM, Richard van der Laan 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).
