hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walco van Loon <wwwa...@gmail.com>
Subject Re: Preferred approach for wire level request "tracing" in HttpClient 4.2/4.3
Date Tue, 07 May 2013 15:25:43 GMT
Hi Oleg,

We have an implementation of tracing to files in place, based on the 4.1
API.

In 4.2.3, there was an issue that a custom ClientConnectionOperator was not
honored everywhere, but that is now fixed. The issue that remains is that
we had a suboptimal approach to close the forked streams if a response is
complete in case of persistent HTTP connections, an event that is not
"signaled" in our custom OperatedClientConnection.

This approach consists of an override of the method
PoolingClientConnectionManager.releaseConnection(), and using reflection to
get our custom connection implementation from the ManagedClientConnection
in order to close the forked file input/output streams we allocated earlier.

Regards,
Walco


On Tue, May 7, 2013 at 10:38 AM, Oleg Kalnichevski <olegk@apache.org> wrote:

> On Tue, 2013-05-07 at 09:34 +0200, Walco van Loon wrote:
> > Hi Stephen,
> >
> > Good question.
> >
> > The wire log is not sufficient to fulfill our requirement of being able
> to
> > storing HTTP requests/response pairs in a specific directory format (one
> > directory per source/destination host/day).
> >
> > Regards,
> > Walco
> >
> >
>
> Walco
>
> What specifically are you having difficulties with: implementing trace
> logging or making the standard pooling connection manager use your
> custom connection class?
>
> Oleg
>
>
> > On Tue, May 7, 2013 at 5:58 AM, Stephen J. Butler
> > <stephen.butler@gmail.com>wrote:
> >
> > > What's deficient about the built in wire log?
> > >
> > > http://hc.apache.org/httpcomponents-client-ga/logging.html
> > >
> > >
> > > On Mon, May 6, 2013 at 3:39 PM, Walco van Loon <wwwalco@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm currently in the process of upgrading HttpClient from 4.1 to 4.2,
> > > (but
> > > > also looking at the changes in 4.3-beta1) and meeting some
> challenges on
> > > > the way.
> > > >
> > > > One of them is the replacement of deprecated API, most notably
> > > > org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager.
> > > >
> > > > Previously we created a subclass of ThreadSafeClientConnManager to
> > > > implement wire level HTTP request/response pair tracing for debugging
> > > > purposes. To achieve this we implemented a subclass of
> > > > DefaultClientConnection that writes all HTTP requests and associated
> > > > responses to disk, by using a specific
> > > > org.apache.http.io.Session(Input|Output)Buffer implementation,
> analogous
> > > to
> > > > org.apache.http.impl.conn.LoggingSession(Input|Output)Buffer. We
> used the
> > > > DefaultClientConnectionOperator hook to expose our implementation of
> > > > DefaultClientConnection to ThreadSafeClientConnManager.
> > > >
> > > > The drawback of our current approach is that we used a rather ugly
> way
> > > > (using reflection) to close the forked input and output streams in an
> > > > override of ThreadSafeClientConnManager.releaseConnection() because
> > > > DefaultClientConnection instances are wrapped in a
> > > ManagedClientConnection
> > > > instance and the managed DefaultClientConnection was not directly
> > > > accessible. Due to API changes, this hack is no longer possible in
> 4.2.
> > > >
> > > > What would be the preferred approach to implement this functionality
> in
> > > > 4.2/4.3?
> > > >
> > > > Regards,
> > > > Walco
> > > >
> > >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message