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