Hi Jon,
I agree with your point of view, considering these assumptions:
- user can't know in advance how big the size of response is
- allocating memory in advance without knowning how much will be used
is uneconomical.
But API doesnt state the memory should actually be alocated.
It can be interpreted as a maximum to allocate if needed
size, wich is better than infinite, in the sense you can tell it to be
comfortable big (in terms of HTML docs e.g. 1MByte), without
forcing servlet engine to actually alocating, only to treat the overriding
this limit as an implicit commit to the response.
I see such a limit more as a way to deal with some errors, like
an infinite loop writing html.
regards,
Cezar.
On Tue, 7 Sep 1999, Jon Saville wrote:
> Geoff,
>
> I agree with a lot of your comments. This issue isn't quite as cut-and-dried as
> I first imagined (like much of life :). However, I still think my proposal
> holds: provide an 'infinite' response buffer that grows as required.
>
> In practice this solution is no worse than letting the user choose the buffer
> size - both are open to abuse.
>
> In important ways it's better: if the server manages the buffer growth, then the
> servlet designer is less tempted to make compromises like 'I could theoretically
> need 100Gb for this response, so that's what I'll set my buffer to'.
>
> On general principles, I think we should only go so far in catering for poor
> servlet design. Of course we should try to minimise it, but even with buffer
> management in the server, a servlet can still run away and create enourmous
> attributes, or any number of other bad solutions.
>
> Fixed sized buffers feel like a compromise (with no offense to the servlet API
> team, who have done an amazing job). I say fixed size because they are fixed as
> soon as anything is written, and so for many servlets creating dynamic content
> their actual size is irrelevant.
>
> You say it's bad practice to return a table with a potentially infinite number
> of rows, and I agree. So what size of response buffer should that servlet
> designer set? 100 rows, 1000? Do we want the designer requesting large buffers
> all the time?
>
> I guess it's a compromise between efficiency, safety, the ability to return an
> error code after you've started, and cleaness of the API. We have to decide what
> balance we want between these goals.
>
> I'd be delighted for someone to kill this thread dead, but I'm not yet
> convinced... :)
>
> jon
>
> Geoff Soutter wrote:
> >
> > 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
>
> --
> 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
