On 22/10/2013 20:41, Bob DeRemer wrote: > > >> -----Original Message----- >> From: Mark Thomas [mailto:ma...@apache.org] >> Sent: Tuesday, October 22, 2013 3:34 PM >> To: Tomcat Developers List >> Subject: Re: websocket connection (at startup) between 2 webapps in same >> Tomcat 7.0.47 instance hangs indefinitely >> >> On 22/10/2013 16:17, Mark Thomas wrote: >>> On 18/10/2013 22:09, Bob DeRemer wrote: >>>> Hi Guys, >>>> >>>> >>>> >>>> In our implementation, we have a gateway app that uses jsr websockets >>>> to communication with our main application server. In a small >>>> system, we want to run them both on a single Tomcat instance using >>>> the same Tomcat NIO connector, but directing to different respective >>>> WS paths. This works fine if you deploy the MAIN first, then the GW >>>> - so that MAIN is already up and running. If you restart Tomcat when >>>> both webapps are deployed - and the GW (client) starts first, it >>>> hangs indefinitely in the following code trying to establish a WS >>>> connection: >>>> >>>> >>>> >>>> Is this a bug or a known limitation when a client/server in the same >>>> webapp try to connect at startup? >>> >>> It certainly shouldn't hang indefinitely - I'll take a look. >> >> I have fixed the indefinite hang. There is now a user configurable IO timeout >> the defaults to 5 seconds. >> >> If you enable parallel starting of containers (set startStopThreads on the >> host to >> more than 1) you might be able to work around this but I haven't tested it. >> >> To avoid random timing issues, you'll still need to handle the failure and >> retry >> after a short wait. >> > > Outta curiosity, what was going on? Also, will this be in 7.0.48? > Thx for such a quick turnaround - bob
All the IO was configured to use infinite timeouts (that would be my fault). The client app started, made an HTTP request to initiate the connection. The connector was listening on the socket since init() has been called (default is to bind on init) but the acceptor thread had not been started so the connection was not processed. The client then started to block, waiting for the response. Since the client was in a ServletContextListener it blocked. That in turn blocked the start of the content which in turn blocked the styart sequence. Since the start sequence was blocked the connectors were never going to be started which is when the acceptors start so you had a deadlock. The reason it worked when you deployed while Tomcat was running was that the connectors were all up and running handling connections so nothing blocked. This was never going to work regardless of the order the apps start in because the acceptor doesn't start until after all the web applications have started. Yes, I have just back-ported it to 7.0.48. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
