On Fri, 2009-01-23 at 13:18 -0500, natarajan_va...@emc.com wrote: > Oleg, > It is name of the thread.
This does not make any sense as there is no way multiple requests could be executed over the same connection based on blocking I/O using a single thread. Oleg > What else should I look for? Any other ideas > to investigate or fix this problem? > > Thanks > Valli > > -----Original Message----- > From: Oleg Kalnichevski [mailto:ol...@apache.org] > Sent: Friday, January 23, 2009 8:02 AM > To: HttpClient User Discussion > Subject: RE: stream corruption > > On Fri, 2009-01-23 at 01:32 -0500, natarajan_va...@emc.com wrote: > > Oleg, > > > > I see following in wire log. The content gets mixed when this happens. > > Does the message look correct? > > > > There is nothing unusual about the log as HttpClient is perfectly > capable of executing requests simultaneously when configured to run with > a threading safe HTTP connection manager. HTTP messages transmitted > concurrently naturally appear mixed in the wire log > > Is SubmitterThread name of a class or name of a thread? > > Oleg > > > 2009-01-22 19:48:06,239 DEBUG header [SubmitterThread]>> "POST > > /indexserver/?ftRequestHandler=BatchRequest HTTP/1.1[\r][\n]" > > 2009-01-22 19:48:06,239 DEBUG header [SubmitterThread]>> "POST > > /indexserver/?ftRequestHandler=BatchRequest HTTP/1.1[\r][\n]" > > 2009-01-22 19:48:06,239 DEBUG header [SubmitterThread]>> "User-Agent: > > Jakarta Commons-HttpClient/3.0.1[\r][\n]" > > 2009-01-22 19:48:06,239 DEBUG header [SubmitterThread]>> "User-Agent: > > Jakarta Commons-HttpClient/3.0.1[\r][\n]" > > 2009-01-22 19:48:06,239 DEBUG header [SubmitterThread]>> "Host: > > myhost:9200[\r][\n]" > > 2009-01-22 19:48:06,239 DEBUG header [SubmitterThread]>> "Host: > > myhost:9200[\r][\n]" > > 2009-01-22 19:48:06,239 DEBUG header [SubmitterThread]>> > > "Content-Length: 8899[\r][\n]" > > 2009-01-22 19:48:06,239 DEBUG header [SubmitterThread]>> > > "Content-Length: 46427[\r][\n]" > > 2009-01-22 19:48:06,239 DEBUG header [SubmitterThread]>> "[\r][\n]" > > 2009-01-22 19:48:06,239 DEBUG header [SubmitterThread]>> "[\r][\n]" > > > > -----Original Message----- > > From: Natarajan, Valli > > Sent: Thursday, January 22, 2009 2:46 PM > > To: HttpClient User Discussion > > Subject: RE: stream corruption > > > > Oleg, > > > > Please let me know if you need any additional information. Could you > > provide more info/pointer on "XML based object serialization"? > > > > Thanks > > Valli > > > > -----Original Message----- > > From: Oleg Kalnichevski [mailto:ol...@apache.org] > > Sent: Thursday, January 22, 2009 2:37 PM > > To: HttpClient User Discussion > > Subject: Re: stream corruption > > > > natarajan_va...@emc.com wrote: > > > Oleg, thanks for adding your comments. We call releaseConnection > > method > > > in finally. Can you think of anything else which might cause this > > > problem? Again, I'm not saying that this is a bug in httpclient and > > > thank you for confirming. I am seeking some help to fix the problem > > that > > > we have. > > > > > > > There is simply not enough information to make any more or less > informed > > > > guesses. Consider using XML based object serialization so you could > > actually see what gets corrupted. > > > > Oleg > > > > > > > > > > > > m_multiThreadedHttpConnectionManager = new > > > MultiThreadedHttpConnectionManager(); > > > m_client = new > > > HttpClient(m_multiThreadedHttpConnectionManager); > > > > > > > > > PostMethod post = new PostMethod(url); > > > try { > > > post.setRequestEntity(new > > > InputStreamRequestEntity(serializeObject(request))); > > > > > > NameValuePair[] pair = new NameValuePair[1]; > > > pair[0] = new NameValuePair(name, value); > > > post.setQueryString(pair); > > > m_client.executeMethod(post); > > > > > > if (post.getStatusCode() == 200) { > > > ObjectInputStream responseStream = new > > > ObjectInputStream(post.getResponseBodyAsStream()); > > > return responseStream.readObject(); > > > } > > > return post.getStatusText(); > > > } > > > finally > > > { > > > post.releaseConnection(); > > > } > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
