OK, I'll have a go at that tomorrow. I should note that it doesn't *always* fail for me. However I haven't yet been able to predict when it will work and when it won't. I did run it earlier with trace7 logging and basically saw no messages for the connections that were stalling. The trunk code I checked out was quite recent, and I did confirm I had all the latest fixes in place.
I'll send logs and annotations once I've collected them. Thanks Eric. - Steve ________________________________________ 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 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 seconds Can you grab trace at e.g. LogLevel INFO proxy_wstunnel_module:trace8 And annotate the timing a bit for what you do in the client? Is it possible you have an un-updated trunk from several weeks ago? There was an optimization put in and backed out that might have broke some of these same things for a very short window. On Thu, Jul 17, 2014 at 2:09 PM, Steve Zweep <steve.zw...@watchguard.com> wrote: > 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 and server > works well except that an Apache thread is held open for each connection > (which is expected). With ProxyWebsocketAsync enabled, these threads are no > longer seen, again as expected. I see two issues though: > > 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. > > 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? > > > > 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? > > > > Thanks > > > > - Steve > > > > ----------- > > Steve Zweep | Senior Software Engineer > > WatchGuard Technologies, Inc. | www.watchguard.com > > > > 905.804.2143 > > steve.zw...@watchguard.com > > -- Eric Covener cove...@gmail.com
