On Thursday, July 3, 2003, at 10:44 AM, Michael Becke wrote:
I'm wondering: *if* the HttpParser.readLine method (and subsequent
calls to .readRawLine) is called much more frequently than other
methods/classes that tap into InputStream, perhaps a start would be
to modify the code in .readRawLi
I'm wondering: *if* the HttpParser.readLine method (and subsequent
calls to .readRawLine) is called much more frequently than other
methods/classes that tap into InputStream, perhaps a start would be to
modify the code in .readRawLine to use a BufferedReader+
BufferedInputStream. That might
On Wednesday, July 2, 2003, at 10:38 PM, Michael Becke wrote:
I'm not sure if there is a real reason. It is probably because
HttpClient does not do much with the input stream other than read
status/headers. Any large content should be handled by the user and
could therefore be buffered.
The
I'm not sure if there is a real reason. It is probably because
HttpClient does not do much with the input stream other than read
status/headers. Any large content should be handled by the user and
could therefore be buffered.
The socket input stream is also used directly at a number of points
Hi,
I'm using the Slide webdav client libs (1.0.16) and have noticed a
higher than expected CPU load from HttpClient (1.x) doing socket
reading.
Closer examination revealed that when I do webdav .puts, the high CPU
consumers are .readLine()s calls to the socket. For some
reason, use of the Xr
