Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Received-SPF: pass (nike.apache.org: domain of Natarajan_Valli@emc.com
 designates 128.222.32.20 as permitted sender)
From: Natarajan_Valli@emc.com
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: stream corruption
Date: Wed, 21 Jan 2009 18:30:39 -0500
Message-ID: 
 <7775458F94A771469DE0D8F473E7C598086762AD@CORPUSMX10C.corp.emc.com>
In-Reply-To: <4977A94D.3070102@apache.org>
Thread-Topic: stream corruption
Thread-Index: Acl8HHwTEXBPhBRFTBqkpaRVSuml6QAAiFbA
References: 
 <7775458F94A771469DE0D8F473E7C598085DCDC0@CORPUSMX10C.corp.emc.com>
 <fa14d5020901211006m6221f3bej64e1679c4266a9b4@mail.gmail.com>
 <7775458F94A771469DE0D8F473E7C598085DCE72@CORPUSMX10C.corp.emc.com>
 <fa14d5020901211031j6c985715k4da78c59fd5aa007@mail.gmail.com>
 <7775458F94A771469DE0D8F473E7C598085DCEB7@CORPUSMX10C.corp.emc.com>
 <fa14d5020901211153w77d59d6an73581380acfdce28@mail.gmail.com>
 <7775458F94A771469DE0D8F473E7C59808676117@CORPUSMX10C.corp.emc.com>
 <3C1617187464854DBCF0B0F60ECC6EEA079AC16B@paems351.starbucks.net>
 <7775458F94A771469DE0D8F473E7C598086761E2@CORPUSMX10C.corp.emc.com>
 <3C1617187464854DBCF0B0F60ECC6EEA079AC1B5@paems351.starbucks.net>
 <4977A94D.3070102@apache.org>
To: <httpclient-users@hc.apache.org>

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.

=20
         m_multiThreadedHttpConnectionManager =3D new
 MultiThreadedHttpConnectionManager();
         m_client =3D new
HttpClient(m_multiThreadedHttpConnectionManager);
=20
=20
         PostMethod post =3D new PostMethod(url);
         try {
             post.setRequestEntity(new
InputStreamRequestEntity(serializeObject(request)));
=20
             NameValuePair[] pair =3D new NameValuePair[1];
             pair[0] =3D new NameValuePair(name, value);
             post.setQueryString(pair);
             m_client.executeMethod(post);
=20
             if (post.getStatusCode() =3D=3D 200) {
                     ObjectInputStream responseStream =3D new
ObjectInputStream(post.getResponseBodyAsStream());
                     return responseStream.readObject();
             }
		 return post.getStatusText();
		}
		finally=20
	  {
            post.releaseConnection();
        }


-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]=20
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()
>=20
> Or some other method to flush the socket - the status has nothing to
do with the response body.
>=20
> =20

I do not mean to hijack the discussion, but I thought I should mention=20
that HttpMethod#releaseConnection would take care of reading content to=20
the end of the message and ensuring the connection was released in a=20
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=20
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=20
> (page) 206-314-2054 or 2063142054@archwireless.net
>=20
> -----Original Message-----
> From: Natarajan_Valli@emc.com [mailto:Natarajan_Valli@emc.com]=20
> Sent: Wednesday, January 21, 2009 1:39 PM
> To: httpclient-users@hc.apache.org
> Subject: RE: stream corruption
>=20
> We read status text when return code is not 200
>=20
> post.getStatusText()
>=20
> Is that enough?=20
>=20
> Thanks
> Valli
>=20
> -----Original Message-----
> From: Pete Keyes [mailto:PKeyes@starbucks.com]=20
> Sent: Wednesday, January 21, 2009 1:23 PM
> To: HttpClient User Discussion
> Subject: RE: stream corruption
>=20
> That will fail to clear the connection stream any time the HTTP return
> code is not 200.
>=20
> You must always completely read the HTTP response - or face
corruption.
>=20
> =20
> ...Pete
> Starbucks Coffee Co.
> 2601 Utah Ave S.
> Seattle, WA. 98134
> (work) 206-318-5933
> (cell) 206-226-4552=20
> (page) 206-314-2054 or 2063142054@archwireless.net
>=20
> -----Original Message-----
> From: Natarajan_Valli@emc.com [mailto:Natarajan_Valli@emc.com]=20
> Sent: Wednesday, January 21, 2009 12:00 PM
> To: httpclient-users@hc.apache.org
> Subject: RE: stream corruption
>=20
> Yes all defaults.
>=20
> Code snippet
>=20
>         m_multiThreadedHttpConnectionManager =3D new
> MultiThreadedHttpConnectionManager();
>         m_client =3D new
HttpClient(m_multiThreadedHttpConnectionManager);
>=20
>=20
>         PostMethod post =3D new PostMethod(url);
>         try {
>             post.setRequestEntity(new
> InputStreamRequestEntity(serializeObject(request)));
>=20
>             NameValuePair[] pair =3D new NameValuePair[1];
>             pair[0] =3D new NameValuePair(name, value);
>             post.setQueryString(pair);
>             m_client.executeMethod(post);
>=20
>             if (post.getStatusCode() =3D=3D 200) {
>                     ObjectInputStream responseStream =3D new
> ObjectInputStream(post.getResponseBodyAsStream());
>                     return responseStream.readObject();
>             }
>=20
>=20
> -----Original Message-----
> From: raykroeker@gmail.com [mailto:raykroeker@gmail.com] On Behalf Of
> Raymond Kroeker
> Sent: Wednesday, January 21, 2009 11:53 AM
> To: HttpClient User Discussion
> Subject: Re: stream corruption
>=20
> What about any retry params.  I'm guessing you're using the defaults
> there too?
>=20
> On Wed, Jan 21, 2009 at 10:44,  <Natarajan_Valli@emc.com> 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: raykroeker@gmail.com [mailto:raykroeker@gmail.com] 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,  <Natarajan_Valli@emc.com> 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: raykroeker@gmail.com [mailto:raykroeker@gmail.com] 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,  <Natarajan_Valli@emc.com> 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 =3D 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: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>
>>>
>>>
>>>
---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>
>>>
>>
>>
>> --
>> ---------------------------------------------------------
>> Raymond Kroeker
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
>>
>=20
>=20
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org