OK, I know I said that I wanted to put off deeper analysis until post 1.1, but the thought of threads hanging indefinitely waiting for tcp connections to die has been keeping me up at night. Not all inter-server HTTP connections will be made via the service registry (e.g. accessing media files, attachments, etc), so we could wind up blocking threads indefinitely on the server, too.
The fix I committed as part of MH-7555 changed the default behavior to specify a 60 second connection timeout and 60 second socket timeout. I'm fine changing this, though, if there's good reason to do so. Thanks, Josh On Tue, Apr 5, 2011 at 5:07 PM, Josh Holtzman <[email protected]>wrote: > I'd like to put off the deeper analysis until after the 1.1 release. In > general, the services making calls to one another do so through the service > registry, which is dynamic, so the "other end" of most http requests should > be up and running. > > Still, we may want to specify a timeout by default. I'm just not sure what > a reasonable value might be. We don't want to terminate large file > downloads prematurely, for instance, from an overloaded server that's > pausing due to a full GC (I know, this shouldn't be happening either). > > Do you think this value should be a connection timeout (time to initial > connection), a socket timeout (time between packets), or should we require > that the client specify both? > > For now, I think the most conservative change is to support the old > behavior and API, but enable clients to specify both a connection and a > socket timeout. Do you plan to set these to something on the order of a > minute for the capture agent? > > Also, if you want to verify that this is in fact the problem that's leading > to the CA pausing, you can keep tabs on open HTTP connections made through > the trusted http client in a JMX console such as jconsole. See attached > screenshot. > > Thanks, > Josh > > > On Tue, Apr 5, 2011 at 4:37 PM, Christopher Brooks > <[email protected]>wrote: > >> This works for me. But in general, shouldn't everyone who is making >> short request/blocking requests want to call this? E.g. only those >> making longer running requests would call the original one? >> >> I'd like to potentially head off problems others might be having but >> not realise it since we make a lot of connections quickly and most >> don't. Thoughts on the high level analysis of the problem? Is this >> unlikely to be a significant factor in the issue? >> >> Chris >> >> On Tue, 05 Apr 2011 16:24:30 -0700 Josh Holtzman >> <[email protected]> wrote: >> >> > I've added this to the comments at MH-7555: >> > >> > We can add a new method with a timeout, defaulting to infinite if >> > none is specified. So the current clients of this API need not >> > change, but the Capture Agent can make use of the new method if it >> > helps. >> > >> > HttpResponse execute(HttpUriRequest httpUriRequest, long timeout, >> > TimeUnit timeUnit) >> > >> > What do you think? >> > >> > Josh >> > >> > On Tue, Apr 5, 2011 at 3:23 PM, Christopher Brooks >> > <[email protected]>wrote: >> > >> > > Hey Josh et all, >> > > >> > > In dealing with a fairly obscure bug in the capture agent, >> > > http://opencast.jira.com/browse/MH-7543 , we're eyeballing the >> > > DefaultHttpClient connection timeout of infinite. If for whatever >> > > reason this client never returns, it could starve the caller. I'd >> > > love to get some comments on whether it would be reasonable to add a >> > > connection timeout and, if so, what a good value would be. >> > > >> > > The specific ticket for this hypothesis is at >> > > http://opencast.jira.com/browse/MH-7555 >> > > >> > > Regards, >> > > >> > > Chris >> > > >> > > -- >> > > Christopher Brooks, BSc, MSc >> > > ARIES Laboratory, University of Saskatchewan >> > > >> > > Web: http://www.cs.usask.ca/~cab938 >> > > Phone: 1.306.966.1442 >> > > Mail: Advanced Research in Intelligent Educational Systems >> > > Laboratory Department of Computer Science >> > > University of Saskatchewan >> > > 176 Thorvaldson Building >> > > 110 Science Place >> > > Saskatoon, SK >> > > S7N 5C9 >> > > >> >> >> >> -- >> Christopher Brooks, BSc, MSc >> ARIES Laboratory, University of Saskatchewan >> >> Web: http://www.cs.usask.ca/~cab938 >> Phone: 1.306.966.1442 >> Mail: Advanced Research in Intelligent Educational Systems Laboratory >> Department of Computer Science >> University of Saskatchewan >> 176 Thorvaldson Building >> 110 Science Place >> Saskatoon, SK >> S7N 5C9 >> > >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
