On 6/16/09 2:40 PM, "Oleksiy Stashok" <Oleksiy.Stashok_at_Sun.COM> wrote:
> 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?
>
>>
>> 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 :-)
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.
>
> 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
>