You are exactly right. eggOnMe = true
Further investigation showed that I was not setting the read (so)
timeout as I thought. Then when I actually *was* setting soTimeout, I
found a bug in our own application that was ignoring the timeout value
from my own configuration - so instead of my expected "quick" timeout,
httpclient was being set to a normal, much longer timeout. I simply
wasn't waiting long enough for our default timeout value to expire.
Consequently, I opted to do what one of the previous messages in this
thread suggested - utilize HttpMethod::abort() to achieve an absolute
timeout, as our business requirements do not differentiate from
connection timeout or remote read timeout. For this I have now
utilized a mechanism very similar to httpclient's own
TimeoutController class combined with HttpMethod::abort(). This
approach works wonderfully - ending the http operation regardless of
the state of the connection or read operations.
Thanks a bunch - and sorry for the confusion.
-Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
|