What are actually valid use cases for explicitly setting one's own HttpClient instance? With "valid" I mean use cases other than working around the broken connection management in the HTTP transport?
Andreas On Sat, Sep 18, 2010 at 10:51, Amila Suriarachchi <[email protected]> wrote: > > > On Sat, Sep 18, 2010 at 12:34 AM, Glen Daniels <[email protected]> > wrote: >> >> (New thread for discussing $subject.) >> >> So, for 1.6 it would be great if we could finalize our HTTP management >> stuff, >> and have a clean set of APIs / patterns that we can have documented and >> FAQ'ed. >> >> This thread can break off into sub-threads if desired, but things I think >> we >> need to get right include the following: >> >> * Do we re-use HTTPClient / MultithreadedHTTPConnectionManager by default? >> >> My answer here would be yes, but the code currently uses any MHCM that it >> finds in the context hierarchy - so if you want to have a separate one >> per-operation or per-message, you can just drop it in to the right >> context. >> I think it's critical that the default behavior is as friendly as possible >> to >> the common use-cases, though. > > So we need to define what the common use-case is. > > I think the httpClient look up algorithm should looks like this, > > looks for cached http client object and if found use it > looks for cached MHCM object and if found create a new httpClient per > invocation. > if both options not available create a new http Client per invocation. > > All lookups should happen in the message context. > > So the default is to create new httpClient. This way users can override > default option for high load situations. > > thanks, > Amila. > > >> >> * Can we upgrade to HTTPClient v4? >> >> I haven't investigated this yet - has anyone played with this to know how >> challenging or not the migration is? >> >> * Are our APIs good enough? >> >> In particular, can we offer enough flexibility to the end-user via >> easy-to-understand APIs / properties? >> >> * Are our tests adequate? >> >> I think not yet. We need at least to have small tests that prove re-use >> is >> working, tests for ServiceClient/OperationClient/Stubs, tests for >> rejiggering >> various properties, and ideally a full build will run a 5000-iteration >> loop >> sequence to test that the connection starvation problem hasn't snuck back >> in >> (particularly critical on Windows). >> >> * Other stuff? >> >> What am I missing? >> >> Thanks, >> --G >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Amila Suriarachchi > WSO2 Inc. > blog: http://amilachinthaka.blogspot.com/ > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
