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?
Thanks.
WBR,
Alexey.
>
>>
>> Thanks.
>>
>> WBR,
>> Alexey.
>