DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560 HttpClient loops endlessly while trying to retrieve status line --- Additional Comments From [EMAIL PROTECTED] 2003-12-11 07:26 --- Adrian, this is a wise (+1-worthy) solution. Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Reading Chunked Stream using HttpClient
Hi, We have a an application which sends chunked input stream for a URL request. We are using HttpClient to get the response. The chunked response sent by the application is actually a motion image. The motion image is retrieved by the first GET command operation and will be send as the sequential data. Therefore, display application should display the sequential data with dividing the data into an image-unit. In this case, boundary character string --myboundary is fixed as an index. What is the best way of handling this type of response and storing each image data in a byte[] array , and using a new byte[] array when we see --myboundary in the stream. The URL looks like http://172.16.101.113/image?speed=20 and the response headers are Content-Type: image/jpeg Thank you all in advance srini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reading Chunked Stream using HttpClient
Srinivas, I understand that you do not mean HTTP's chunked transfer encoding by the term chunked stream and chunked input. I guess you are using a Multipart-MIME like content encoding. HttpClient does NOT however deal with the content and does not provide any means to parse the contents format. You must therefore either parse the response stream by yourself or use an existing Multipart-MIME library to decode the multipart stream. You may want to have a look at the Commons FileUpload code which does exactly that or at Multipart-MIME Email handling code which must do a similar thing. Regards Odi Srinivas Vemula wrote: Hi, We have a an application which sends chunked input stream for a URL request. We are using HttpClient to get the response. The chunked response sent by the application is actually a motion image. The motion image is retrieved by the first GET command operation and will be send as the sequential data. Therefore, display application should display the sequential data with dividing the data into an image-unit. In this case, boundary character string --myboundary is fixed as an index. What is the best way of handling this type of response and storing each image data in a byte[] array , and using a new byte[] array when we see --myboundary in the stream. The URL looks like http://172.16.101.113/image?speed=20 and the response headers are Content-Type: image/jpeg Thank you all in advance srini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- _ NOSE applied intelligence ag ortwin glück [www] http://www.nose.ch software engineer [email] [EMAIL PROTECTED] hardturmstrasse 171 [pgp key] 0x81CF3416 8005 zürich [office] +41-1-277 57 35 switzerland [fax] +41-1-277 57 12 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reading Chunked Stream using HttpClient
Odi, Yes, you are right. If we access the URL from broweser, it opens up a file dialog box and starts filling in bytes and there is no end to it unless we close the window. We are able to read the stream with get.getResponseBodyAsStream(). The stream is image bytes delimited by an ascii string --myboundary, So I guess i just need figure out an easy way of cutting this stream into bytes for every occurence of that string. That sounds more of an IO issue. Any ideas? Thanks for your time and response. Srini Ortwin Glück wrote: Srinivas, I understand that you do not mean HTTP's chunked transfer encoding by the term chunked stream and chunked input. I guess you are using a Multipart-MIME like content encoding. HttpClient does NOT however deal with the content and does not provide any means to parse the contents format. You must therefore either parse the response stream by yourself or use an existing Multipart-MIME library to decode the multipart stream. You may want to have a look at the Commons FileUpload code which does exactly that or at Multipart-MIME Email handling code which must do a similar thing. Regards Odi Srinivas Vemula wrote: Hi, We have a an application which sends chunked input stream for a URL request. We are using HttpClient to get the response. The chunked response sent by the application is actually a motion image. The motion image is retrieved by the first GET command operation and will be send as the sequential data. Therefore, display application should display the sequential data with dividing the data into an image-unit. In this case, boundary character string --myboundary is fixed as an index. What is the best way of handling this type of response and storing each image data in a byte[] array , and using a new byte[] array when we see --myboundary in the stream. The URL looks like http://172.16.101.113/image?speed=20 and the response headers are Content-Type: image/jpeg Thank you all in advance srini - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Srinivas Vemula +91 40 23547826- Ext 201 Associate Consultant +91 40 23541447 (Fax) Mensamind+91 98497-42720 (Mobile) Hyderabad India http://www.mensamind.com DISCLAIMER The information contained in this e-mail is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email you must not copy, distribute or take any further action in reliance on it. You should delete it and notify the sender immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reading Chunked Stream using HttpClient
Srinivas Vemula wrote: We are able to read the stream with get.getResponseBodyAsStream(). The stream is image bytes delimited by an ascii string --myboundary, So I guess i just need figure out an easy way of cutting this stream into bytes for every occurence of that string. Just wrap this InputStream and scan for your boundary. It would certainly help if you had included the chunk length in your boundary string. But I don't see a problem here. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [Bug 25370] - exception during writeRequest leaves the conn ection un-released
I'm forwarding this to the list. The conversation that originally started on
Bug 25370 took a turn and uncovered a potentially critical problem. The
original bug was about releasing the connection back to the pool. This
conversation is about closing the underlying socket under the same
situation. I'm not sure if we want to keep track of it under the same bug or
a new one.
The good news is, the solution is fairly simple and Oleg lists it below. The
same code can fix Bug 25370 if we release the connection after closing the
socket.
Thanks
Moh
P.S. This is my second attempt at sending this to the list. Hope it's not a
duplicate.
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 4:54 PM
To: Rezaei, Mohammad A.
Subject: RE: [Bug 25370] - exception during writeRequest leaves the conn
ection un-released
Mohammad,
I do not think we should be taking this discussion off-line. I'd really
appreciate if you posted your comments to the but report. Some other folks
may have something to contribute, for instance, Mike who actually authored
Multithreaded connection manager
On Wed, 2003-12-10 at 22:28, Rezaei, Mohammad A. wrote:
handleException is only called when inside the WrapperOutputStream
methods. A *read* failure while sending a file (or a runtime
exception, etc) will not be caught here. Am I missing something?
You certainly have a point here. I guess HttpMethoDirector#executeMethod may
simply do the following
try {
execute
}
catch (IOException e) {
// close the damn thing
}
catch (RuntimeException e) {
// close the damn thing
}
finally {
// see if it is safe to release connection
// (no unread response content left
// or not response body not expected)
}
Would you like to whip up a patch or shall I do it?
Cheers
Oleg
Thanks
Moh
-Original Message-
From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2003 4:24 PM
To: Rezaei, Mohammad A.
Subject: Re: [Bug 25370] - exception during writeRequest leaves the conn
ection un-released
On Wed, 2003-12-10 at 22:07, Rezaei, Mohammad A. wrote:
9M. Reusing that socket will have very unpredictable results (it
acts
like a black hole and won't throw any exception unless a timeout is
specified). It would be prudent to close the socket on an IOException
or a RuntimeException. Do you agree? Should I file this under a
separate bug or under this one?
Mohammad,
The wrapper class should take of that:
/**
* Closes the connection and conditionally converts exception
to recoverable.
* @param ioe the exception that occurred
* @return the exception to be thrown
*/
private IOException handleException(IOException ioe) {
// keep the original value of used, as it will be set to
false by close().
boolean isRecoverable = HttpConnection.this.used;
HttpConnection.this.close();
if (ioe instanceof InterruptedIOException) {
return new IOTimeoutException(ioe.getMessage());
} else if (isRecoverable) {
LOG.debug(
Output exception occurred on a used connection.
Will treat as recoverable.,
ioe
);
return new HttpRecoverableException(ioe.getMessage(),
ioe);
} else {
return ioe;
}
}
Cheers,
Oleg
Thanks
Moh
--- Additional Comments From [EMAIL PROTECTED] 2003-12-10 20:01
---
if (CAUSE_RANDOM_ERROR) if (Math.random() ERROR_RATE) throw new
IOException(Random error, for testing only!);
OK. I see.
From reading the code, it seems the outputstream is wrapped
insideWrappedOutputStream which rethrows any exceptions *inside its
methods*
asrecoverable. There are two problems with this approach.
Mohammad, actually that is that way it is supposed to be.
IOException
thrown when retrieving request content or runtime exceptions are not
recoverable HTTP transport exceptions and should not be treated as
such
Thanks for the clarification. You still have to be extremely
careful if you enable auto recovery on write.
Agreed. I personally am not in favour of having auth-recovery
activated per default, but according to the feedback we were getting
from our users the majority did not appear to share that conviction.
How about this fix: add
catch (IOException e) {
releaseConnection = true;
throw e;
} catch (RuntimeException e) {
releaseConnection = true;
throw e;
}
to the last try clause in HttpMethodDirector#executeWithRetry ?
That can be done. I would not like to change 2.0 branch, though, for
DO NOT REPLY [Bug 24560] - HttpClient loops endlessly while trying to retrieve status line
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24560 HttpClient loops endlessly while trying to retrieve status line [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-11 22:56 --- Patch committed. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
