In our particular case, NIO doesn't imply any underlying implementation.
It just means it's non blocking. Underneath we can use NIO, NIO.2/AIO or
even blocking I/O.
WBR,
Alexey.
On 08/24/2011 06:31 PM, Justin Lee wrote:
> I hate encoding the impl names in methods like that. What if we want
> to use the AIO stuff later? I'd prefer "NonBlocking" over any
> specific implementation hints. But either way, probably better to be
> explicit in the method name rather than rely on method parameters.
>
> On 8/24/11 12:25 PM, Ryan Lubke wrote:
>> 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.
>>>>
>>>
>>