On Jan 8, 2007, at 3:06 AM, Garrett Rooney wrote:
On 1/7/07, Leo Simons <[EMAIL PROTECTED]> wrote:
On Dec 23, 2006, at 4:06 AM, [EMAIL PROTECTED] wrote:
> * src/test/java/org/apache/speedyfeed/test/BasicTest.java
> (BasicServlet.doGet): Remember to close the stream.
(...)
> @@ -57,8 +59,12 @@
> byte buffer[] = new byte[1024];
> int len;
>
> - while ((len = in.read(buffer)) != -1) {
> - out.write(buffer, 0, len);
> + try {
> + while ((len = in.read(buffer)) != -1) {
> + out.write(buffer, 0, len);
> + }
> + } finally {
> + out.close();
> }
> }
> }
Just FYI, in servlets, IIRC (not done servlets in a while, perhaps
someone can confirm my rusty memory) it is usually better to not
flush
() or close() any container-provided output stream. This allows the
servlet container to do various things better (like http pipes, post
request filters, ...); I do know it matters with WebLogic.
The servlet container is required to close the stream appropriately
by the servlet spec.
See, the reason I put in the explicit close was that I wasn't ever
getting it called without that,
Hmm. From the servlet spec (v.2.4):
--
SRV.5.5 Closure of Response Object
When a response is closed, the container must immediately flush all
remaining
content in the response buffer to the client. The following events
indicate that the servlet has satisfied the request and that the
response object is to be closed:
• The termination of theservice method of the servlet.
• The amount of content specified in the setContentLength method of
the re-
sponse has been written to the response.
• The sendError method is called.
• The sendRedirect method is called.
--
getOutputStream()
public ServletOutputStreamgetOutputStream()
throws IOException
Returns aServletOutputStream suitable for writing binary data in the
response. The servlet container does not encode the binary data.
Callingflush()ontheServletOutputStreamcommitstheresponse.Eitherthis
method orgetWriter() may be called to write the body, not both.
--
so I think my memory was correct -- sometime after your service(),
the response object should be closed, which eventually should lead to
the response stream being closed, too.
and thus the filter (which is dumb and
buffers all the data up so it can process it once at the end, due to
lack of a way to slowly feed data to Abdera) didn't work. Is this
indicative of a problem in Jetty?
It might be. I took a brief stroll through its source to check but
got a little lost.
However, its quite unlikely there's an actual problem in "normal
mode" jetty -- it is used in production environments every day. If
there's a problem, its more likely to be somewhere with the test
framework and how it interacts with abdera.
Or is it just that sticking work
inside the close method is a Bad Idea (tm) in the first place?
That's definitely the case. If you depend on a stream closing to
signal the end of a request or a response, you're screwing up http
pipelining. That's why HTTP has content length and the like :)
/LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
