Jon,
Funny, your thoughts sound exactly like me initial reaction when I first
read the 2.2 spec. However, I then realised the errors of my ways :-)
It seems to me that this API was designed with one intention in mind: try
and minimise server crashes related to "run-away" servlets chewing up all
the memory. This is a fundamental problem of the current servlet
achitecture - I guess you'd need a "servlet aware" VM to prevent this?
People who write their own buffering scheme can easily crash the server like
this. So, provide them with an obvious alternative and make it "crash proof"
by specifying the upper limit of the buffer... it's a damage limitation
excercise!
But, I suppose you could alternatively say the intention was: try and
encourage good coding practice. It's not a good idea to create a query page
with an unlimited number of return rows, for instance, or to assume that a
user will wait an unbounded amount of time for the page to arrive.
Over all, I think it's a reasonable compromise.... although sometimes I wish
the servlet API team explained the rationale behind their design
decisions...!
What bugs me about this whole buffering thing is that the buffering scheme I
have written for 2.0/2.1 servlets works just as well as the one in 2.2.
However, the things that only the servlet API could do for buffering were
not included... e.g. buffering a RD.include() and letting me extract the
results from the buffer. :-(
Geoff
-----Original Message-----
From: Jon Saville <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Tuesday, 7 September 1999 18:05
Subject: Re: 2.2 spec issues: one trivial, one serious (response buffering)
>Jason Hunter wrote:
>>
>> > I believe the call to setBufferSize should have the ability to
>> > return the actual buffer size allocated, which may be more *or less*
>> > than that requested. This would allow the container to balance buffer
>> > allocation between servlets, and to
>> > refuse outrageously large buffer requests from broken, malicious or
>> > badly coded servlets.
>>
>> If my servlet's malicious, or if I'm a poor coder, then I can still do
>>
>> byte[] buf = new byte[HUGE_VALUE]
>>
>> to chew the server.
>
>True, of course.
>
>> Because the server must follow the setBufferSize() request, it makes
>> it a lot easier to write portable code. It's not just a performance
>> question, it's an issue of how much output a servlet can write and
>> still reset the response with an error code.
>
>I would question just *how* much easier it makes it ;) However, with your
first
>argument you are encouraging a particular programming model, and
implementing it
>in the server: write whatever you like, you can always wipe it later and
start
>again.
>
>In that case, the servlet programmer should be encouraged to buffer the
data
>internally, rather than rely on an external agency, which has an unknown
>implementation and performance.
>
>
>But I accept your point about needing to return an error code having
already
>written some data. But surely it would be a lot cleaner for the container
to
>provide an automatically 'infinite' buffer, and a commit function call.
>
>Most of the servlets I have written generally havn't known when an error
could
>occur, and so I coudn't have set the buffer size in advance unless it was
always
>to the total size of my output. And similarly, in a lot of cases, I don't
know
>that size in advance.
>
>It seems to me it has to be all or nothing. I don't see the advantage of
setting
>the buffer to a particular size, since many servlets are creating dynamic
>output. If we wish to support the ability to change error code, then the
buffer
>should be 'infinite'.
>
>jon
>--
>Jon Saville
>Principle Member of Technical Staff - IP Telephony Program Manager
>
># The opinions expressed in this message are my own and do not
># represent the opinions of others or Signals & Software company policy.
>
>Signals+Software Ltd Tel: +44 (0)20 8 872 9000
>The Heights, Lowlands Road Fax: +44 (0)20 8 872 9001
>Harrow, Middx, HA1 3AW, UK Web: www.sasl.com
>
>___________________________________________________________________________
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff SERVLET-INTEREST".
>
>Archives: http://archives.java.sun.com/archives/servlet-interest.html
>Resources: http://java.sun.com/products/servlet/external-resources.html
>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
