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.
>>>
>>
>