If we could figure out someway to get the test framework to
handle tests for websockets, that would be great. My tests
use both node.js and python with simple ws servers, and
it's been hard trying to figure out how to add that kind of
stuff to the framework. :/
On Jul 17, 2014, at 2:54 PM, Steve Zweep <steve.zw...@watchguard.com> wrote:

> Thanks Eric. 
> 
> BTW, the test setup I have is fairly simple. The websocket server just echoes 
> received messages from any client to all connected clients. I just connect 2 
> clients and send a message to the server from one.  A tcpdump shows the 
> correct 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 threads
> 
> On Thu, Jul 17, 2014 at 2:09 PM, Steve Zweep <steve.zw...@watchguard.com> 
> 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. I would have expected the data from the 
>> server to generate an event resulting in immediate delivery.
> 
> your expectation is consistent with mine -- must be a bug.
> 
> I don't think my ad-hoc testing had a push like that so it's probably 
> something small in the managing of the fds -- no reason for it to not be 
> symmetric
> 
>> 
>> 2.       In attempts to debug this I experimented with
>> ProxyWebsocketAsyncDelay. I observed that when this is used, the 
>> connections never go into async mode. I.e. proxy_tunnel_pump() never returns 
>> SUSPENDED.
>> As a result I see the same thread usage as when ProxyWebsocketAsync is 
>> turned off. Is this expected behavior?
> 
> also not expected
> 
>> Any insights into what is going on here would be helpful. I noticed 
>> that there have been a number of recent changes both to the event mpm 
>> and mod_proxy_wstunnel. Perhaps there are still some known issues with 
>> this code?
> 
> it is definitely new/rough/experimental and trunk-only.  I just added a note 
> to the docs now.  I will try to look this weekend at the two issues above.
> 
> --
> Eric Covener
> cove...@gmail.com

Reply via email to