>
>> Hi Bo,
>>
>>> I noticed that the ACCEPTED and CONNECTED IO events are fired AFTER
>>> the read
>>> interest is registered with the selector. This makes it impossible
>>> to
>>> initialize some connection related state before processing data on
>>> the new
>>> connection. Is it possible to move the selector registration after
>>> firing
>>> the IO events?
>> you're right ACCEPTED and CONNECTED events are fired AFTER read
>> interest registration, but BEFORE any data will be processed on the
>> connection. If you observe different behavior, it could be bug.
>> And unfortunately selector registration should happen before ACCEPTED
>> and CONNECTED events will be fired, cause at that time Connection
>> should be 100% ready for use.
> I saw a race condition between two Grizzly worker threads: one
> processing
> the ACCEPTED event and another processing the READ event. I didn't
> see any
> synchronization that might keep this from happening. Am I missing
> something?
Hmm, which version are you using?
>>
>>>
>>> Another thing, when closing a connection, the READ interest is not
>>> deregistered from the selector and another READ IO event is fired.
>>> This
>>> eventually leads to an EOFException or ClosedChannelException. Is
>>> this a
>>> bug?
>> Do you see this exception? I though it should be hidden by
>> framework :)
>> If you see it in stacktrace - it's bug, if not - it's ok :)
> Well, it was well hidden by the framework ;-) I just thought it
> would be
> cleaner to cancel the SelectionKey to prevent the extra exception
> allocation
> and CPU cycles :-)
Looks like it will not be easy, as SelectionKey operations should be
executed in Selector Thread, so we actually have to register "cancel
SelectionKey operation" from Worker Thread and ask Selector Thread to
execute it, which also doesn't very optimal.
>
> This brings up something else: is there a way to call
> exceptionOccured on
> all filters in the chain and not just the executed ones? I have a
> custom
> filter that needs to know if and what error occurred on the connection
> (EOFException, ClosedChannelException, etc...) before closing.
IMHO, you can register some monitoring filter before TransportFilter
in a FilterChain. Will it work for you?
Thanks.
WBR,
Alexey.
>>
>> Thank you.
>>
>> WBR,
>> Alexey.
>>
>>>
>>> Thanks again
>>> Bo
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>