dev@grizzly.java.net

Re: [http-server] Return blocking or non-blocking streams by default?

From: Ryan Lubke <ryan.lubke_at_oracle.com>
Date: Wed, 24 Aug 2011 09:25:59 -0700

On 8/24/11 9:22 AM, Oleksiy Stashok wrote:
> On 08/24/2011 06:00 PM, Ryan Lubke wrote:
>> 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}().
> I'm fine with that, may be getNIO{InputStream, OutputStream, Reader,
> Writer}, just to be consistent with class names?

Fine by me.

>
> Thanks.
>
> WBR,
> Alexey.
>
>
>
>>
>>>
>>> Thanks.
>>>
>>> WBR,
>>> Alexey.
>>
>