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.
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();
}
-----Original Message-----
From: Oleg Kalnichevski [mailto:[email protected]]
Sent: Wednesday, January 21, 2009 3:02 PM
To: HttpClient User Discussion
Subject: Re: stream corruption
Pete Keyes wrote:
> That isn't what you need to do. You need to:
getResponseBodyAsStream()
>
> Or some other method to flush the socket - the status has nothing to
do with the response body.
>
>
I do not mean to hijack the discussion, but I thought I should mention
that HttpMethod#releaseConnection would take care of reading content to
the end of the message and ensuring the connection was released in a
consistent state. As long as HttpMethod#releaseConnection is called from
a finally clause, there should be no data corruption.
To this date (and I have been involved in maintaining HttpClient for
long 6 years) I cannot recall a single case of confirmed data corruption
due to a bug in HttpClient.
Oleg
> ...Pete
> Starbucks Coffee Co.
> 2601 Utah Ave S.
> Seattle, WA. 98134
> (work) 206-318-5933
> (cell) 206-226-4552
> (page) 206-314-2054 or [email protected]
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, January 21, 2009 1:39 PM
> To: [email protected]
> Subject: RE: stream corruption
>
> We read status text when return code is not 200
>
> post.getStatusText()
>
> Is that enough?
>
> Thanks
> Valli
>
> -----Original Message-----
> From: Pete Keyes [mailto:[email protected]]
> Sent: Wednesday, January 21, 2009 1:23 PM
> To: HttpClient User Discussion
> Subject: RE: stream corruption
>
> That will fail to clear the connection stream any time the HTTP return
> code is not 200.
>
> You must always completely read the HTTP response - or face
corruption.
>
>
> ...Pete
> Starbucks Coffee Co.
> 2601 Utah Ave S.
> Seattle, WA. 98134
> (work) 206-318-5933
> (cell) 206-226-4552
> (page) 206-314-2054 or [email protected]
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, January 21, 2009 12:00 PM
> To: [email protected]
> Subject: RE: stream corruption
>
> Yes all defaults.
>
> Code snippet
>
> 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();
> }
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Raymond Kroeker
> Sent: Wednesday, January 21, 2009 11:53 AM
> To: HttpClient User Discussion
> Subject: Re: stream corruption
>
> What about any retry params. I'm guessing you're using the defaults
> there too?
>
> On Wed, Jan 21, 2009 at 10:44, <[email protected]> wrote:
>> we use standard ones (no customization)
>>
>> org.apache.commons.httpclient.methods.PostMethod
>> org.apache.commons.httpclient.methods.InputStreamRequestEntity (we
>> buffer the serialized java object and pass ByteArrayInputStream to
>> InputStreamRequestEntity).
>>
>> As recommended we re-use HttpClient object and create PostMethod
> object
>> every time by passing url. Also use default params and its values.
>>
>> Thanks
>> Valli
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf Of
>> Raymond Kroeker
>> Sent: Wednesday, January 21, 2009 10:32 AM
>> To: HttpClient User Discussion
>> Subject: Re: stream corruption
>>
>> What about the http methods themselves. Are you using the vanilla
>> versions that come with http client; are you extending them in any
>> way; are you using a request entity for either post/put?
>>
>> Raymond
>>
>> On Wed, Jan 21, 2009 at 10:20, <[email protected]> wrote:
>>> Raymond,
>>>
>>> Thanks for reply.
>>>
>>> 1. Yes & no. The problem re-occurs but things work fine when we
> resend
>>> failed request. So, there is no testcase or data that reproduce the
>>> problem as needed.
>>> 2. I tried to buffer & dump content on server side before calling
>>> ObjectInputStream and readObject in order to see content of
malformed
>>> stream. Unfortunately, the problem did not occur or at least the
>> problem
>>> is delayed for hours...
>>>
>>> Additional information is, we use MultiThreadedHttpConnectionManager
>> on
>>> client side.
>>>
>>> Thanks
>>> Valli
>>>
>>> -----Original Message-----
>>> From: [email protected] [mailto:[email protected]] On Behalf
Of
>>> Raymond Kroeker
>>> Sent: Wednesday, January 21, 2009 10:07 AM
>>> To: HttpClient User Discussion
>>> Subject: Re: stream corruption
>>>
>>> Hi Natarajan,
>>> I've been using hc 3.0.1 for a long while and have never noticed
>>> this issue. I have a couple of questions.
>>>
>>> 1. Can you reproduce the event that causes the error?
>>> 2. Can you see what the content of the malformed stream is?
>>>
>>> If neither of these is true I would suggest that you persist the
>>> request content such that when the error occurs you can troubleshoot
>>> the problem and ask better questions.
>>>
>>> Raymond
>>>
>>> On Wed, Jan 21, 2009 at 09:02, <[email protected]> wrote:
>>>> We use HttpClient version 3.0.1 and recently noticed stream
>>> corruption.
>>>> The corruption is noticed on server side when the server (webapp
>>> running
>>>> in Jboss server) receives those requests. We believe that at some
>>> point
>>>> content of 2 requests are mixed. Is that possible? The problem is
>> very
>>>> intermittent but happens very often.
>>>>
>>>>
>>>>
>>>> Here is the code snippet that receives the stream on server side
>>>>
>>>>
>>>>
>>>> ObjectInputStream reqStream = new
>>>> ObjectInputStream(httpServletReq.getInputStream());
>>>>
>>>> return (IRequest) reqStream.readObject();
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> exception returned by this when problem occurs
>>>>
>>>>
>>>>
>>>> java.lang.NullPointerException
>>>>
>>>> at
>>>>
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1820)
>>>> at
>>>>
>
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719
>>>> )
>>>>
>>>> at
>>>> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
>>>>
>>>> at
>>>>
>
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
>>>> at
>>>>
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
>>>> at
>>>>
>
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719
>>>> )
>>>>
>>>> at
>>>> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
>>>>
>>>> at
>>>> java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
>>>>
>>>>
>>>>
>>>> Any idea to resolve this problem is highly appreciated!
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> Valli
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> ---------------------------------------------------------
>>> Raymond Kroeker
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>>
>> --
>> ---------------------------------------------------------
>> Raymond Kroeker
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
