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 <[email protected]> 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 > > <[email protected]>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 <[email protected]> > 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: [email protected] > For additional commands, e-mail: [email protected] > >
