I removed the apr_pollset_remove() call on line 1978 of event.c. So far it is
working fine for me. Thanks Edward.
- Steve
Edward Lu wrote:
> Seems like the solution is just to remove the extra apr_pollset_remove(); all
> sockets are removed from the pollset when
> one of them is signalled. If
44044496, u64=144044496}}) = 0
>> > [pid 15451] gettimeofday({1406038173, 745644}, NULL) = 0
>> > [pid 15451] epoll_wait(10, {{EPOLLIN, {u32=2843761856,
>> u64=2843761856}}}, 2, 0) = 1
>> > [pid 15451] read(9, "\201\10", 8000)
[pid 15451] writev(8, [{"\201\10", 10}], 1) = 10
> > [pid 15451] read(9, 0xa96084b0, 8000) = -1 EAGAIN (Resource
> temporarily unavailable)
> > [pid 15451] epoll_wait(10, {}, 2, 0)= 0
> > [pid 15451] epoll_ctl(7, EPOLL_CTL
On Fri, Jul 25, 2014 at 12:01 PM, Steve Zweep
wrote:
> ProxyWebsocketAsyncDelay
Currently the default is seconds. If you want millseconds, you have to
add the ms suffix. Maybe the doc needs a tweak, but I think whole
seconds by default is best.
--
Eric Covener
cove...@gmail.com
14 11:38 AM
To: dev@httpd.apache.org
Subject: Re: Question about async mod_proxy_wstunnel and threads
I think I've found the issue; there's an extraneous apr_pollset_remove() call
in event.c:1978. Relevant code (double-slash comments are mine):
/* We only signal once per
2=2843796920,
> u64=2843796920}}) = 0
> [pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 9, {EPOLLIN, {u32=2843796944,
> u64=2843796944}}) = 0
> [pid 15451] gettimeofday({1406038173, 745832}, NULL) = 0
> [pid 15451] futex(0x891ec88, FUTEX_WAIT_PRIVATE, 38, NULL
; unavailable)
>> [pid 15451] epoll_wait(10, {}, 2, 0)= 0
>> [pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 8, {EPOLLIN, {u32=2843796920,
>> u64=2843796920}}) = 0
>> [pid 15451] epoll_ctl(7, EPOLL_CTL_ADD, 9, {EPOLLIN, {u32=2843796944,
>> u64=2843796944}}) = 0
>> [pid 1
43796944}}) = 0
> [pid 15451] gettimeofday({1406038173, 745832}, NULL) = 0
> [pid 15451] futex(0x891ec88, FUTEX_WAIT_PRIVATE, 38, NULL
>
>
> - Steve
>
> -Original Message-
> From: Steve Zweep
> Sent: Monday, July 21, 2014 11:56 AM
> To: 'dev@httpd.apache.o
m: Steve Zweep
Sent: Monday, July 21, 2014 11:56 AM
To: 'dev@httpd.apache.org'
Subject: RE: Question about async mod_proxy_wstunnel and threads
My client and server are based on sample code included with the ws4py package
(http://ws4py.readthedocs.org/en/latest/). We use CherryPy and the ws4py
List
Subject: Re: Question about async mod_proxy_wstunnel and threads
I guess it is kind of telling that we could still respond to the write from
client 2, there are probably more potential errors that make us lose track of
both sides simultaneously.
Can you share your ws client and server if they&#x
makes a difference. Probably won't get to this before Monday
>> though.
>>
>> - Steve
>>
>> -Original Message-
>> From: Yann Ylavic [mailto:ylavic@gmail.com]
>> Sent: Friday, July 18, 2014 4:51 PM
>> To: httpd
>> Subject: Re: Question abou
.com]
> Sent: Friday, July 18, 2014 4:51 PM
> To: httpd
> Subject: Re: Question about async mod_proxy_wstunnel and threads
>
> Hi Steve,
>
> can you still reproduce with the latest APR 1.5.x, notably containing this
> fix: http://svn.apache.org/r1605769.
> I don'
this before Monday though.
- Steve
-Original Message-
From: Yann Ylavic [mailto:ylavic@gmail.com]
Sent: Friday, July 18, 2014 4:51 PM
To: httpd
Subject: Re: Question about async mod_proxy_wstunnel and threads
Hi Steve,
can you still reproduce with the latest APR 1.5.x, notably conta
unk code. The same results were observed.
>
> - Steve
>
>
>
> -Original Message-
>
> From: Eric Covener [cove...@gmail.com]
> Sent: July 17, 2014 9:15 PM
> To: Apache HTTP Server Development List
> Subject: Re: Qu
. The same results were observed.
- Steve
-Original Message-
From: Eric Covener [cove...@gmail.com]
Sent: July 17, 2014 9:15 PM
To: Apache HTTP Server Development List
Subject: Re: Question about async mod_proxy_wstunnel and threads
I am h
9:15 PM
To: Apache HTTP Server Development List
Subject: Re: Question about async mod_proxy_wstunnel and threads
I am having trouble seeing it mis-behave. w/ Async and AsyncDelay, I
am seeing the expected trace messages and when I look at backtraces of
httpd I can see zero threads in wstunnel . If
I am having trouble seeing it mis-behave. w/ Async and AsyncDelay, I
am seeing the expected trace messages and when I look at backtraces of
httpd I can see zero threads in wstunnel . If I send a server msg, I
get it ASAP in the client -- and then I see 1 thread in poll for the
right couple of secon
It's a bit heavy, but perhaps use PhantomJS as a non-default test?
Rick Houser
Web Administration
(517)367-3516
> -Original Message-
> From: Jim Jagielski [mailto:j...@jagunet.com]
> Sent: Thursday, July 17, 2014 5:30 PM
> To: dev@httpd.apache.org
> Subject: Re:
ect packets are sent by the server.
>
> - Steve
>
> -Original Message-
> From: Eric Covener [mailto:cove...@gmail.com]
> Sent: Thursday, July 17, 2014 2:27 PM
> To: Apache HTTP Server Development List
> Subject: Re: Question about async mod_proxy_wstunnel and thre
-Original Message-
From: Eric Covener [mailto:cove...@gmail.com]
Sent: Thursday, July 17, 2014 2:27 PM
To: Apache HTTP Server Development List
Subject: Re: Question about async mod_proxy_wstunnel and threads
On Thu, Jul 17, 2014 at 2:09 PM, Steve Zweep wrote:
> 1. While communicat
On Thu, Jul 17, 2014 at 2:09 PM, Steve Zweep wrote:
> 1. While communication from client to server works well, unsolicited
> messages from the server to clients seem to queue. If the client
> subsequently sends a message back to the server, the original message from
> the server is received.
Hi
I am prototyping a system in which we will have a large number of websocket
connections between multiple clients and a server (potentially) behind
mod_proxy_wstunnel. Currently I am testing a trunk build with the event mpm.
With ProxyWebsocketAsync turned off, communication between client an
22 matches
Mail list logo
