> That'd be grand if its possible (We like the IBM JVMs' speed and more
> detailed thread dumps). We used to subclass httpclient so we could do
> the below, moving the setting of the timeout till after the open.
> HttpClient 3.0 now sets timeout, etc., after the open seemingly so our
> subclass is no longer necessary (Hurray!).
St.Ack,
Could you retest HttpClient 3.0a3 with IBM JRE and let us know if the
problem still persists?
> HttpRecorder duplicates all sent and received to files on disk. It wraps the
> (buffered) socket streams with input/output streams that do the duplication.
> Subsequently, the file is fed to a set of processors to with as they wilt. Link
> extraction is main task performed by processors.
>
> We need to record what was sent over the wire preserving order and all bytes sent
> back and forth (We're trying to archive the web). If there's a less intrusive way
> of getting what we need, we'd love to hear of it.
>
One possibility would be some thing like that:
public class HeritixMethod extends GetMethod {
class HeritixConnectionWrapper extends HttpConnection {
...
}
public int execute(HttpState state, HttpConnection conn)
throws HttpException, IOException {
return super.execute(state, new HeritixConnectionWrapper(conn));
}
}
It's ugly but should prevent you from having to patch HttpClient. A
better solution would be a pluggable HttpConnection implementation. This
will have to wait until 4.0, though
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
