On 8/24/11 5:51 AM, Oleksiy Stashok wrote:
> Hi,
>
> currently in the HttpServer API we have following methods to retrieve
> Input/Output streams and readers/writers:
> /
> Request.getInputStream();
> Request.getInputStream(boolean isBlocking);
>
> Request.getReader();
> Request.getReader(boolean isBlocking);
>
> Response.getOutputStream();
> Response.getOutputStream(boolean isBlocking);
>
> Response.getWriter();
> Response.getWriter(boolean isBlocking);/
>
> if you get stream using method without argument - Grizzly returns
> *non-blocking* version of the stream, so
> /Response.getInputStream() == Response.getInputStream(*false*)/
>
> I'm not sure this is right decision, may be we have to return blocking
> version by default? It can be more intuitive to Servlet users and have
> more predictable behavior.
Makes sense.
> I'm mostly concerned about usage of non-blocking OutputStream, which
> is based on Grizzly asynchronous write queue. Particularly if user
> tries to write large amounts of data on relatively slow connection,
> the async write queue starts to grow quickly... which finally may lead
> to unexpected memory consumption and potentially out of memory error.
> For sure if user is aware of Grizzly NIO streams and wants to leverage
> this feature - he may implement the usecase above accurately, using
> NIOOutputStream.notifyAvailable(...) etc, but what if user is not aware?
>
> May we should return blocking stream version by default, and return
> non-blocking only if it's explicitly asked using isBlocking parameter?
>
> What do you think?
While we're at it, maybe we should deprecate the stream methods that
accept the flag and add getNonBlocking{OutputStream,Writer}().
>
> Thanks.
>
> WBR,
> Alexey.