John Keyes wrote:
My point here is that if I have X requests then there can be
X * CONTENT_LENGTH_CHUNKED
bytes in memory at one time.
I see what you mean. But the above calculation does not make sense:
CONTENT_LENGTH_CHUNKED is a (negative) integer that signals to
HttpClient that you do not
On 25 Feb 2004, at 14:43, Ortwin Glück wrote:
John Keyes wrote:
My point here is that if I have X requests then there can be
X * CONTENT_LENGTH_CHUNKED
bytes in memory at one time.
I see what you mean. But the above calculation does not make sense:
CONTENT_LENGTH_CHUNKED is a (negative)
to implement based on our new preference architecture.
Oleg
-Original Message-
From: John Keyes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 25, 2004 18:54
To: Commons HttpClient Project
Subject: Re: streaming request body
On 25 Feb 2004, at 14:43, Ortwin Glück wrote:
John Keyes
For (a), Oleg's response is correct. You might easily be confused, in
the sense that HttpClient's API inverts the control. It is not that
you write to an OutputStream to send your data, it is that you
provide HttpClient with an InputStream, and it reads that stream and
sends the data.
John Keyes schrieb:
For (a), Oleg's response is correct. You might easily be confused,
in the sense that HttpClient's API inverts the control. It is not
that you write to an OutputStream to send your data, it is that
you provide HttpClient with an InputStream, and it reads that
stream and
John Keyes wrote:
In both cases, it is possible to get the behavior that you desire.
Not it is not. Again think of XXX,000 of requests.
I am getting a little angry by now. C'mon man, we wrote this baby and we
know very well what's possible with it. So please don't tell us it can
not do
Stefan Dingfelder wrote:
I am missing something here from both views. Maybe I am wrong but as I
understand it, I can provide any InputStream. And that must not be a
file on disk (which I dislike also - except for large files or live
streams that cannot be put to memory in total) but can be any
Project
Subject: Re: streaming request body
For (a), Oleg's response is correct. You might easily be confused, in
the sense that HttpClient's API inverts the control. It is not that
you write to an OutputStream to send your data, it is that you
provide HttpClient with an InputStream
John Keyes wrote:
For (a), Oleg's response is correct. You might easily be confused, in
the sense that HttpClient's API inverts the control. It is not that
you write to an OutputStream to send your data, it is that you
provide HttpClient with an InputStream, and it reads that stream
and sends
On 24 Feb 2004, at 14:36, Stefan Dingfelder wrote:
John Keyes schrieb:
For (a), Oleg's response is correct. You might easily be confused,
in the sense that HttpClient's API inverts the control. It is not
that you write to an OutputStream to send your data, it is that
you provide HttpClient
On 24 Feb 2004, at 14:39, Ortwin Glück wrote:
John Keyes wrote:
In both cases, it is possible to get the behavior that you desire.
Not it is not. Again think of XXX,000 of requests.
I am getting a little angry by now. C'mon man, we wrote this baby and
we know very well what's possible with it.
lots_snipped/
Again, comments and feedback or a patch for bug 26070 would be welcome.
Okay, I'll investigate it more and see what I come up with,
-John K
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Ortwin Glück schrieb:
Stefan Dingfelder wrote:
I am missing something here from both views. Maybe I am wrong but as
I understand it, I can provide any InputStream. And that must not be
a file on disk (which I dislike also - except for large files or live
streams that cannot be put to memory
*concurrently*? What kind of application is it, if
I may ask you?
Oleg
-Original Message-
From: John Keyes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 24, 2004 16:59
To: Commons HttpClient Project
Subject: Re: streaming request body
On 24 Feb 2004, at 14:36, Stefan Dingfelder wrote:
John
John Keyes schrieb:
On 24 Feb 2004, at 14:39, Ortwin Glück wrote:
John Keyes wrote:
In both cases, it is possible to get the behavior that you desire.
Not it is not. Again think of XXX,000 of requests.
I am getting a little angry by now. C'mon man, we wrote this baby
and we know very well
to process around 70,000
requests a minute.
-John K
Oleg
-Original Message-
From: John Keyes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 24, 2004 16:59
To: Commons HttpClient Project
Subject: Re: streaming request body
On 24 Feb 2004, at 14:36, Stefan Dingfelder wrote:
John Keyes
Subject: Re: streaming request body
On 24 Feb 2004, at 16:22, Kalnichevski, Oleg wrote:
But a *segment* will be held in memory prior to writing to the output
stream though. For XXX,000 requests I think this is an unreasonable
memory overhead.
John,
Just to make sure I understand you correctly
John Keyes wrote:
method.setRequestBody( ... );
client.execute( method );
So my question is, is there a way to stream the request body rather than
having to store the request in memory prior to writing it on the wire.
setRequestBody accepts an InputStream. You could use a piped stream to
John,
HttpClient's entity enclosing methods (POST, PUT) do support content streaming when
(1) the content length does not need to be automatically calculated or (2)
chunk-encoding is used
Please refer to the following sample applications for details
Unbuffered post:
Thanks for the information guys.
-John K
On 23 Feb 2004, at 13:02, Kalnichevski, Oleg wrote:
John,
HttpClient's entity enclosing methods (POST, PUT) do support content
streaming when (1) the content length does not need to be
automatically calculated or (2) chunk-encoding is used
Please
Guys,
A colleague pointed out to me that this does not in fact resolve the
situation. The solutions pointed out allow me to read the attachment
as a stream. The contents are still held in memory prior to writing it
on the wire. To fully support this you would need access to the
Have a look here:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26070
Thanks
Moh
-Original Message-
From: John Keyes [mailto:[EMAIL PROTECTED]
Sent: Monday, February 23, 2004 3:49 PM
To: Commons HttpClient Project
Subject: Re: streaming request body
Guys,
A colleague pointed
John,
Two separate questions:
a) sending a large post/put request, without buffering it in memory.
b) reading a large response to a request.
For (a), Oleg's response is correct. You might easily be confused, in
the sense that HttpClient's API inverts the control. It is not that you
write to an
23 matches
Mail list logo
