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 2063142...@archwireless.net
-----Original Message-----
From: natarajan_va...@emc.com [mailto:natarajan_va...@emc.com]
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?
Thanks
Valli
-----Original Message-----
From: Pete Keyes [mailto:pke...@starbucks.com]
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 2063142...@archwireless.net
-----Original Message-----
From: natarajan_va...@emc.com [mailto:natarajan_va...@emc.com]
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 = 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: raykroe...@gmail.com [mailto:raykroe...@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, <natarajan_va...@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: raykroe...@gmail.com [mailto:raykroe...@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_va...@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: raykroe...@gmail.com [mailto:raykroe...@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_va...@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 = 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-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
--
---------------------------------------------------------
Raymond Kroeker
---------------------------------------------------------------------
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
