Return-Path: Delivered-To: apmail-hc-httpclient-users-archive@www.apache.org Received: (qmail 95356 invoked from network); 21 Jan 2009 22:35:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Jan 2009 22:35:23 -0000 Received: (qmail 90366 invoked by uid 500); 21 Jan 2009 22:35:22 -0000 Delivered-To: apmail-hc-httpclient-users-archive@hc.apache.org Received: (qmail 90229 invoked by uid 500); 21 Jan 2009 22:35:22 -0000 Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "HttpClient User Discussion" Delivered-To: mailing list httpclient-users@hc.apache.org Received: (qmail 90218 invoked by uid 99); 21 Jan 2009 22:35:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jan 2009 14:35:22 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [199.233.178.252] (HELO paems365.starbucks.net) (199.233.178.252) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jan 2009 22:35:13 +0000 Received: from paems363.starbucks.net (10.4.11.42) by paems365.starbucks.net (10.3.49.24) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 21 Jan 2009 14:34:50 -0800 Received: from paems351.starbucks.net ([::1]) by paems363.starbucks.net ([::1]) with mapi; Wed, 21 Jan 2009 14:34:51 -0800 From: Pete Keyes To: HttpClient User Discussion Date: Wed, 21 Jan 2009 14:34:51 -0800 Subject: RE: stream corruption Thread-Topic: stream corruption Thread-Index: Acl8Afo9nsQRuZjnR/yzwO8L2e61SAAAGA+QAAMAgfAAAIZEUAAAJCyAAAAUWCAAADbysAAAi+pQAAD8miA= Message-ID: <3C1617187464854DBCF0B0F60ECC6EEA079AC28A@paems351.starbucks.net> References: <7775458F94A771469DE0D8F473E7C598085DCDC0@CORPUSMX10C.corp.emc.com> <7775458F94A771469DE0D8F473E7C598085DCE72@CORPUSMX10C.corp.emc.com> <7775458F94A771469DE0D8F473E7C598085DCEB7@CORPUSMX10C.corp.emc.com> <7775458F94A771469DE0D8F473E7C59808676117@CORPUSMX10C.corp.emc.com> <3C1617187464854DBCF0B0F60ECC6EEA079AC16B@paems351.starbucks.net> <7775458F94A771469DE0D8F473E7C598086761E2@CORPUSMX10C.corp.emc.com> <3C1617187464854DBCF0B0F60ECC6EEA079AC1B5@paems351.starbucks.net> <7775458F94A771469DE0D8F473E7C598086761F4@CORPUSMX10C.corp.emc.com> <3C1617187464854DBCF0B0F60ECC6EEA079AC1D7@paems351.starbucks.net> <7775458F94A771469DE0D8F473E7C5980867622E@CORPUSMX10C.corp.emc.com> In-Reply-To: <7775458F94A771469DE0D8F473E7C5980867622E@CORPUSMX10C.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org That should be handled by HttpClient's connection manager - answer: no >From what I've read it would be bad to close the stream. =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 -----Original Message----- From: Natarajan_Valli@emc.com [mailto:Natarajan_Valli@emc.com]=20 Sent: Wednesday, January 21, 2009 2:11 PM To: httpclient-users@hc.apache.org Subject: RE: stream corruption I will try. One more question, is it necessary to close the stream after reading? InputStream instream =3D post.getResponseBodyAsStream(); byte[] buffer =3D new byte[4096]; int len; while ((len =3D instream.read(buffer)) > 0) { outstream.write(buffer, 0, len); } Instream.close(); // is it necessary? Or would help? -valli -----Original Message----- From: Pete Keyes [mailto:PKeyes@starbucks.com]=20 Sent: Wednesday, January 21, 2009 1:52 PM To: HttpClient User Discussion Subject: RE: stream corruption That is the most common error I see in this news group associated with "corrupt http streams". Be careful with the "as string"...it will memory very quickly if the response happens to be large. =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 -----Original Message----- From: Natarajan_Valli@emc.com [mailto:Natarajan_Valli@emc.com]=20 Sent: Wednesday, January 21, 2009 1:47 PM To: httpclient-users@hc.apache.org Subject: RE: stream corruption I'll try reading response calling either getResponseBodyAsStream or getResponseBodyAsString. However, I am sure the tests return HTTP code 200 always. Is there anything else that could cause this problem? Thanks Valli -----Original Message----- From: Pete Keyes [mailto:PKeyes@starbucks.com]=20 Sent: Wednesday, January 21, 2009 1:42 PM To: HttpClient User Discussion Subject: RE: stream corruption 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. =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 -----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 We read status text when return code is not 200 post.getStatusText() Is that enough?=20 Thanks Valli -----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 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. =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 -----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 Yes all defaults. Code snippet m_multiThreadedHttpConnectionManager =3D new MultiThreadedHttpConnectionManager(); m_client =3D new HttpClient(m_multiThreadedHttpConnectionManager); PostMethod post =3D new PostMethod(url); try { post.setRequestEntity(new InputStreamRequestEntity(serializeObject(request))); NameValuePair[] pair =3D new NameValuePair[1]; pair[0] =3D new NameValuePair(name, value); post.setQueryString(pair); m_client.executeMethod(post); if (post.getStatusCode() =3D=3D 200) { ObjectInputStream responseStream =3D new ObjectInputStream(post.getResponseBodyAsStream()); return responseStream.readObject(); } -----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 What about any retry params. I'm guessing you're using the defaults there too? On Wed, Jan 21, 2009 at 10:44, 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, 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, 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 --------------------------------------------------------- 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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org For additional commands, e-mail: httpclient-users-help@hc.apache.org