On Sat, 2024-03-16 at 16:19 +0100, Richard Tippl wrote: > Thanks for your email, I do have a few follow up points. > > I see no way to use a custom HttpClientConnectionOperator with > the PoolingHttpClientConnectionManager, > the manager itself and the Builder seem to always make an instance of > the > Default with no way of choosing my own. > I'm guessing this is because 5.4 is still in Alpha version and this > will be > implemented later down the line? >
There is a protected internal constructor that takes HttpClientConnectionOperator as a parameter. This constructor could be made public if needed. > Adding callback methods at key points of connection establishment > sounds > great, > but I can't figure out a good way to pass a running timer between the > before and after methods without resorting to one returning Object > which > the second accepts. > The conventional way of passing around custom objects is through HttpContext as context attributes. I imagine those callback methods should take HttpContext as their parameter. Hope this helps Oleg > I think the best for me would be to implement my own > DetachedSocketFactory > and TlsSocketStrategy. > TlsSocketStrategy can be wrapped in the same way I did > with ConnectionSocketFactory, > and DetachedSocketFactory can be made to return a special Socket that > can > also measure its own connection times. > TlsSocketStrategy I can manually set through the > PoolingHttpClientConnectionManagerBuilder, however I cannot do that > with > the DetachedSocketFactory. > > These solutions, if a bit hacky, would work for me without having to > reimplement (or copy) large parts of the Operator into my codebase, > but also would require either a way to configure > DetachedSocketFactory or > use a custom HttpClientConnectionOperator instance. > > Thanks. > > Richard > > On Sat, Mar 16, 2024 at 11:54 AM Oleg Kalnichevski <ol...@apache.org> > wrote: > > > On Fri, 2024-03-15 at 21:56 +0100, Richard Tippl wrote: > > > > > > > ... > > > > > There are 2 issues with this approach, as far as i can tell, I > > > can't > > > measure these times separately, and in the newest alpha version > > > of > > > 5.4 the > > > interface I'm using has been deprecated and replaced by the > > > DefaultHttpClientConnectionOperator, which performs all of the > > > connection > > > steps in a single method call. > > > > > > Am I missing some easier way to plug into the flow of creating a > > > connection > > > and getting the ability to measure what I wish to measure? > > > > One would need to provide a custom HttpClientConnectionOperator as > > of > > 5.4 in order to plug-in custom connection initialization logic. > > What we > > could do though is to add a number of callback methods #beforeThis, > > #afterThis, #beforeThat, #afterThat to > > DefaultHttpClientConnectionOperator in order to make it easier to > > collect various performance data. > > > > Feel free to raise a PR at GitHub with such changes. > > > > > > > Will it still be > > > possible after the deprecated interfaces get removed? Is there a > > > way > > > I > > > could measure both socket open and SSL handshake separately? > > > > Through a custom HttpClientConnectionOperator. > > > > Oleg > > > > > > ------------------------------------------------------------------- > > -- > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > For additional commands, e-mail: > > httpclient-users-h...@hc.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
