Indeed - thanks for the tidbit!
> On Mar 10, 2014, at 0:45, Oleksiy Stashok <oleksiy.stashok_at_oracle.com> wrote:
>
> Hi Gregory,
>
>> Could you elaborate the drawbacks?
> the one for which I can't a workaround is that you have to allocate ByteBuffer for asynchronous read(...) operation. At the time you allocate this ByteBuffer you don't know if there's data available for reading or not (unlike NIO.1, where first you get an event, that there's some data to be read and only then you allocate a ByteBuffer). IMO this drawback can potentially lead to DoS attacks.
>
> Makes sense?
>
> Thanks.
>
> WBR,
> Alexey.
>>
>> On Mar 7, 2014, at 13:41, Oleksiy Stashok <oleksiy.stashok_at_oracle.com> wrote:
>>
>>> Hi Ming Qin,
>>>
>>>> On 07.03.14 06:46, Ming Qin wrote:
>>>> Hi Everyone:
>>>>
>>>> On the page of https://grizzly.java.net/transportsconnections.html, there is a statement likes"Grizzly 2.3 has two Transport implementations: NIO TCP and NIO UDP, which is based on Java NIO, though in the future, support for NIO.2 based transports and SCTP will be added once JDK 7 is available."
>>>>
>>>> How does Grizzly switch back and forth between NIO and NIO2 implementations ?
>>> for now we're not planning to implement NIO2 based Grizzly Transport, because of certain NIO2 drawbacks, SCTP is on our list, but at the moment we just don't have time for it (for sure contributions are welcome).
>>>
>>> Thanks.
>>>
>>> WBR,
>>> Alexey.
>