>So, currently
>* The connection level socket timeout represents the default value
>settable upon connection initialization.
>* The optional method level socket timeout represents the
>value settable
>upon method execution which overrides the default one.
>
>The old 2.0-style socket and connect timeout settings correspond to
>those of the connection manager (at least IMO).
>
>Let me now if you think that all this stuff does (or does not) make any
>sense
Hmmm.. With the 3.0 api, there are 3 levels: connection manager, http
client, http method.
With the 2.0 API, even though we wanted per method control, we used to call
httpClient.setTimeout();
The 2.0 code in HttpClient.java is very simple:
public synchronized void setTimeout(int newTimeoutInMilliseconds) {
this.timeoutInMilliseconds = newTimeoutInMilliseconds;
}
Specifically, we set it to 20000 to "ping" a server and then set it to 0 to
execute the real call. It worked just fine (that is, it would never timeout
when set to zero).
With 3.0, the same call sequence broke: when we set the timeout to 0 after
it had been set to 20000, it would actually timeout. The 3.0 code from
HttpClient:
public synchronized void setTimeout(int newTimeoutInMilliseconds) {
this.httpConnectionManager.getParams().setSoTimeout(newTimeoutInMilliseconds
);
}
I think if this code would use this.getParams() instead, it would work as
before. We've changed our code to use the httpMethod.setTimeout(), which
makes more sense; but I thought I'd bring it up as it is a non-trivial
change in the behavior.
>
>I reviewed the code found only two instances where the root exception
>was not propagated to the caller
>
Exception patch looks good to me.
BTW, we haven't had any issues with Alpha 1.
Thanks
Moh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
