On Sat, Aug 18, 2012 at 3:49 AM, Stephen J. Butler <[email protected] > wrote:
> Depends on the connection manager you're using. There's a > multi-threaded example on the site: > > > http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/examples/MultiThreadedExample.java?view=markup > > Is there something there that doesn't cover your use case? > Thanks Stephen, I do use the MT ConMan like so: HttpClient newHttpClient = new HttpClient(new MultiThreadedHttpConnectionManager()); HttpConnectionManagerParams params = newHttpClient.getHttpConnectionManager().getParams(); params.setConnectionTimeout(this.getTimeoutMillis()); params.setSoTimeout(this.getTimeoutMillis()); The logs I have from our server (this is all running in an old version of our server that talks to other 3rd party servers via HttpClient 3.1) show that some requests take a long time and those threads get Thread.stop()'ed from a watchdog thread. I know Thread.stop() is a no-no but that's old code we have out in use. I do not have the info yet on what the timeout values are for HttpClient. I plan on asking for logs for a test where HttpClient times out /before/ the watchdog thread kicks in. What happens when you execute an HC request and the timeout is exceeded? Does HttpClient throw an exception and close the connection? Or return an HTTP error code? Each of our request/response payload includes a correlation GUID that match requests and responses in this and other parts of the system. What I see now is that at some point after some time of sending and receiving OK, our code picks up the wrong response, in this odd pattern: - good IO - sends request ID B and gets back a response ID A. - sends request ID C and gets back a response ID B. - sends request ID D and gets back a response ID C. ... and so on 6 timess - back to good IO What is weird is that ONE of the GUID that come back in one of the mismatched responses is the GUID of a request that Thread.stop()'ed. My guess is that, somehow, the thread was stop()'ed while waiting to read from the socket and that another thread picked up that stream. Is that possible in HC using an MT ConMan? I've not been able to reproduce this error yet in our test suites. How differently is multi-threading dealt with in 4.x? Any thought appreciated. Thank you, Gary > > On Fri, Aug 17, 2012 at 1:40 PM, Gary Gregory <[email protected]> > wrote: > > Hi All: > > > > Is the HttpClient class in version 3.1 thread safe? > > > > I am seeing some odd behavior and I am looking for quick answer before I > > dive down the rabbit hole... > > > > Gary > > > > -- > > E-Mail: [email protected] | [email protected] > > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 > > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- E-Mail: [email protected] | [email protected] JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
