Really? Hmm. <Location /examples> ProxyPass http://localhost:8080/examples ProxyPassReverse http://localhost:8080/examples ProxyPass ws://localhost:8080/examples ProxyPassReverse ws://localhost:8080/examples </Location>
Debug did show something interesting. This was 2 browsers, Firefox and Chrome at the same time.: [Mon Mar 18 19:32:47.311154 2013] [proxy_wstunnel:debug] [pid 16104:tid 4487745536] mod_proxy_wstunnel.c(228): [client ::1:61267] AH02445: woke from poll(), i=1 [Mon Mar 18 19:32:47.311197 2013] [proxy_wstunnel:debug] [pid 16104:tid 4487745536] mod_proxy_wstunnel.c(237): [client ::1:61267] AH02446: sock was readable [Mon Mar 18 19:32:47.311415 2013] [proxy_wstunnel:debug] [pid 16105:tid 4487208960] mod_proxy_wstunnel.c(228): [client ::1:61271] AH02445: woke from poll(), i=1 [Mon Mar 18 19:32:47.311434 2013] [proxy_wstunnel:debug] [pid 16105:tid 4487208960] mod_proxy_wstunnel.c(237): [client ::1:61271] AH02446: sock was readable [Mon Mar 18 19:32:47.397291 2013] [proxy_wstunnel:debug] [pid 16104:tid 4487745536] mod_proxy_wstunnel.c(228): [client ::1:61267] AH02445: woke from poll(), i=1 [Mon Mar 18 19:32:47.397341 2013] [proxy_wstunnel:debug] [pid 16104:tid 4487745536] mod_proxy_wstunnel.c(253): [client ::1:61267] AH02448: client was readable [Mon Mar 18 19:32:47.397352 2013] [reqtimeout:info] [pid 16104:tid 4487745536] [client ::1:61267] AH01382: Request body read timeout [Mon Mar 18 19:32:47.397359 2013] [proxy_wstunnel:debug] [pid 16104:tid 4487745536] mod_proxy_wstunnel.c(129): (70007)The timeout specified has expired: [client ::1:61267] AH02442: error on client - a p_get_brigade [Mon Mar 18 19:32:47.397379 2013] [proxy:debug] [pid 16104:tid 4487745536] proxy_util.c(2028): AH00943: WS: has released connection for (localhost) [Mon Mar 18 19:32:47.410563 2013] [proxy_wstunnel:debug] [pid 16105:tid 4487208960] mod_proxy_wstunnel.c(228): [client ::1:61271] AH02445: woke from poll(), i=1 [Mon Mar 18 19:32:47.410618 2013] [proxy_wstunnel:debug] [pid 16105:tid 4487208960] mod_proxy_wstunnel.c(237): [client ::1:61271] AH02446: sock was readable [Mon Mar 18 19:32:47.511173 2013] [proxy_wstunnel:debug] [pid 16105:tid 4487208960] mod_proxy_wstunnel.c(228): [client ::1:61271] AH02445: woke from poll(), i=1 [Mon Mar 18 19:32:47.511220 2013] [proxy_wstunnel:debug] [pid 16105:tid 4487208960] mod_proxy_wstunnel.c(237): [client ::1:61271] AH02446: sock was readable [ [Mon Mar 18 19:32:51.180493 2013] [proxy_wstunnel:debug] [pid 16105:tid 4487208960] mod_proxy_wstunnel.c(228): [client ::1:61271] AH02445: woke from poll(), i=1 [Mon Mar 18 19:32:51.180545 2013] [proxy_wstunnel:debug] [pid 16105:tid 4487208960] mod_proxy_wstunnel.c(253): [client ::1:61271] AH02448: client was readable [Mon Mar 18 19:32:51.180558 2013] [reqtimeout:info] [pid 16105:tid 4487208960] [client ::1:61271] AH01382: Request body read timeout [Mon Mar 18 19:32:51.180565 2013] [proxy_wstunnel:debug] [pid 16105:tid 4487208960] mod_proxy_wstunnel.c(129): (70007)The timeout specified has expired: [client ::1:61271] AH02442: error on client - ap_get_brigade [Mon Mar 18 19:32:51.180585 2013] [proxy:debug] [pid 16105:tid 4487208960] proxy_util.c(2028): AH00943: WS: has released connection for (localhost) 100% Reproducible, and when accessing Tomcat7 directly (no httpd), the sockets are verified okay for 7hrs. (left running while away). Any insight? mod_reqtimeout? On 2013-03-18, at 1:50 PM, Jim Jagielski wrote: > I cannot recreate either. Anything in the log (debug level) which > may be pertinent? > > On Mar 18, 2013, at 12:43 PM, Jamie Johnson <jej2...@gmail.com> wrote: > >> I haven't done any serious testing but haven't seen this in my simple >> application. I will try to duplicate the issue with the snakes example and >> see where I land. >> >> Perhaps this is something that one of the devs can shed more light on though. >> >> >> On Mon, Mar 18, 2013 at 11:59 AM, Nathan Quinlan <nathan.quin...@gmail.com> >> wrote: >> Seems to work fine with the correct Location settings. ;) >> >> However I have found that when proxying to Tomcat 7 (what I'm testing with) >> the tunnel lasts for about 20 seconds or so and then terminates. >> After a few reloads it appears as though Tomcat still has the socket open >> (as timeout I setup to be 5 minutes) but the connection appears to be >> failing in httpd. >> >> This connection shutdown appears to occur within httpd because when I >> apachectl -k restart the browsers connection resumes as expected. >> In this case I'm testing Tomcat's /examples/websocket/snakes.html and the >> player state hangs in < 30 seconds and browser thinks socket is closed BUT >> when restarting httpd the connection resumes as far as Tomcat is concerned. >> >> I've taken a capture of the traffic using Wireshark for browser <-> httpd >> and there isn't anything odd in the last packet sent, it just stops. >> >> Any ideas? The approximate 20 second cut off seems odd and httpd is >> basically stock 2.4.4 compiled with the merged in wstunnel module. >> >> On 2013-03-18, at 7:29 AM, Jim Jagielski wrote: >> >>> ProxyPass /whatever ws://websocket-srvr.example/com/ >>> >>> Basically, the new submodule adds the 'ws' and 'wss' scheme >>> to the allowed protocols between the client and the backend, so >>> you tell Apache that you'll be talking 'ws' with the >>> backend (same as ajp://whatever sez that httpd will be >>> talking ajp to the backend). >>> >>> On Mar 17, 2013, at 9:52 AM, Jamie Johnson <jej2...@gmail.com> wrote: >>> >>>> I am able to duplicate your issue, not 100% sure what's happening there or >>>> if that configuration is supposed to be supported or not. The following >>>> works fine though >>>> >>>> <Location /dynamic> >>>> ProxyPass http://10.0.1.11:8080/WebSockets >>>> ProxyPassReverse http://10.0.1.11:8080/WebSockets >>>> </Location> >>>> <Location /dynamic/ws> >>>> ProxyPass ws://10.0.1.11:8080/WebSockets/ws >>>> ProxyPassReverse ws://10.0.1.11:8080/WebSockets/ws >>>> </Location> >>>> >>>> would be good to hear exactly how this is expected to be configured, >>>> perhaps we're landing in the wrong portion of the code when they are in >>>> the same location? >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Mar 17, 2013 at 9:43 AM, Jamie Johnson <jej2...@gmail.com> wrote: >>>> So your setup is a little different than mine, I have the following and >>>> even with images it works >>>> >>>> ProxyPass /ws ws://10.0.1.11:8080/WebSockets/ws >>>> >>>> ProxyPassReverse /ws ws://10.0.1.11:8080/WebSockets/ws >>>> >>>> >>>> ProxyPass /test http://10.0.1.11:8080/WebSockets >>>> >>>> ProxyPassReverse /test http://10.0.1.11:8080/WebSockets >>>> >>>> I will try with a similar setup to yours now and see where I get. >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Mar 17, 2013 at 9:19 AM, Jamie Johnson <jej2...@gmail.com> wrote: >>>> Hmmm... I am only serving one html file in my test...I will add some more >>>> and see if I notice the same >>>> >>>> On Mar 17, 2013 8:57 AM, "Nathan Quinlan" <nathan.quin...@gmail.com> wrote: >>>> I don't have any rewrite rules. >>>> <Location /dynamic> >>>> #ProxyPass ajp://localhost:8009/dynamic >>>> ProxyPass http://localhost:8080/dynamic >>>> ProxyPass ws://localhost:8080/dynamic >>>> >>>> And >>>> Alias "/static" "/opt/sitestatic" >>>> <Directory "/opt/sitestatic"> >>>> >>>> Now, with the ProxyPassReverse present about 50% of the files transfered >>>> get that 404 -as- served by Tomcat (based on Apache-Coyote/1.1 header). >>>> Despite the URL being something like /static/hello.jpg. >>>> >>>> On 2013-03-17, at 6:33 AM, Jamie Johnson wrote: >>>> >>>>> Also I have a different rewrite rule for http and ws...not sure that is >>>>> required though >>>>> >>>>> On Mar 17, 2013 6:31 AM, "Jamie Johnson" <jej2...@gmail.com> wrote: >>>>> Definitely interesting. I had gotten this working but I was only serving >>>>> sine html through tomcat and I made the endpoints different while testing >>>>> even though they were coming from the same application in tomcat...mine >>>>> are birth being proxied as well no rewrite involved >>>>> >>>>> On Mar 17, 2013 12:35 AM, "Nathan Quinlan" <nathan.quin...@gmail.com> >>>>> wrote: >>>>> I do not know why but for some reason ProxyPassReverse doesn't play nice >>>>> with Tomcat and I had to include an extra line for the ws: protocol. >>>>> >>>>> Additionally with the ProxyPassReverse present I would see crazy response >>>>> 404 headers when loading say 30 small images on screen like: >>>>> Content-Length 1003 >>>>> Content-Type text/html;charset=utf-8 >>>>> Date Sun, 17 Mar 2013 04:09:28 GMT >>>>> Server Apache-Coyote/1.1 >>>>> >>>>> The interesting thing was that in this case the image being loaded had a >>>>> totally different URL (/a proxy to Tomcat, /b static content) and was >>>>> handled outside of Tomcat via a rewrite rule and a <Location> but when >>>>> the ProxyPassReverse was removed images were fine. >>>>> Images that were not 404 show up in the access_log of httpd but the 404 >>>>> files with the crazy header do not. >>>>> >>>>> >>>>> >>>>> On 2013-03-16, at 12:37 PM, Jamie Johnson wrote: >>>>> >>>>>> I just took a quick stab and it was pretty straight forward, I just >>>>>> added lines like this and it appeared to work properly >>>>>> >>>>>> ProxyPass /ws http://hostname:port/ws/websocket >>>>>> ProxyPassReverse /ws http://hostname:port/ws/websocket >>>>>> >>>>>> again, this appeared to work properly I am next going to be giving SSL a >>>>>> try to see if things work properly with that. If what I did above is >>>>>> not right any info would be appreciated. Also should I expect the SSL >>>>>> support to work? >>>>>> >>>>>> >>>>>> On Sat, Mar 16, 2013 at 12:21 PM, Jamie Johnson <jej2...@gmail.com> >>>>>> wrote: >>>>>> I've just built the latest code on trunk to test proxy_wstunnel, but >>>>>> haven't seen any documentation on how to configure it. Is this >>>>>> available anywhere? >>>>>> >>>>> >>>> >>>> >>>> >>> >> >> >