Hi Alexey and Ryan,
I also think it is so reasonable that blocking stream version is default and
"getNIO{InputStream, Reader, OutputStream, Writer}" looks fine.
Ryan wrote:
> While we're at it, maybe we should deprecate the stream methods that accept
the flag and add getNonBlocking{OutputStream,Writer}().
Then, how can we get the blocking stream without the flag?
Current Request.java and Response.java returns NIO{InputStream, Reader,
OutputStream, Writer} class type.
I think current "Response.getOutputStream( true )" returns NIOOutputStream's
blocking mode.
You means that Response.getNIOOutputStream() returns NIOOutputStream's
non-blocking mode and Response.getOutputStream() returns NIOOutputStream's
blocking mode?
Regards,
Bongjae Chang
From: Ryan Lubke <ryan.lubke_at_oracle.com>
Reply-To: <dev_at_grizzly.java.net>
Date: Wed, 24 Aug 2011 09:25:59 -0700
To: <dev_at_grizzly.java.net>
Subject: Re: [http-server] Return blocking or non-blocking streams by
default?
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.
>>>
>>
>>
>
>