Hi,
from message Kshitiz wrote about several SelectorHandlers I understood,
that possibly we have something wrong...
If we have several SelectorHandlers of the same protocol - looks we have
problem.
As usual key return procedure looks like
controller.registerKey(SelectionKey key, int ops, Protocol protocol)...
now, if we have for example two TCP SelectorHandlers - it means all the
keys will be reregistered on first found TCP SelectorHandler, never on
second one.
Think it's the bug...
WBR,
Alexey.
Jeanfrancois Arcand wrote:
> Hi Kshitiz,
>
> Kshitiz Saxena wrote:
>> Hi Jeanfrancois,
>>
>> Please see my comments inline.
>>
>> Thanks,
>> Kshitiz
>>
>> Jeanfrancois Arcand wrote:
>>> Hi Kshitiz,
>>>
>>> Kshitiz Saxena wrote:
>>>> Hi,
>>>>
>>>> One question on SelectorHandler:
>>>>
>>>> We can add multiple SelectorHandler associated with Controller
>>>> using addSelectorHandler(). So we can have multiple listeners for
>>>> same controller. It is ok till we have all handlers for same
>>>> protocol as they can be handled by same protocol chain. However we
>>>> may need different protocol chain, if we have handlers for
>>>> different protocol. As an example for TCP we will need ReadFilter,
>>>> however for UDP we need UDPReadFilter.
>>>
>>> The latest version of ReadFilter works for both UDP and TCP.
>>>
>> This is great :)
>>>
>>> Now protocol chain should be provided based on underlying
>>>> protocol. This decision need to be made in poll() method of
>>>> ProtocolChainInstanceHandler. This method does not have any
>>>> argument. Please provide inputs on how to achieve this.
>>>
>>> It would be better to use two Controller in that case, one for TCP,
>>> one for UDP if they can't be handled by a sinfle filter.
>>>
>> Please let me know of possible usecase for poll() method. What can be
>> achieved using poll() method?
>
> I didn't have that scenario in mind when we designed the
> InstanceHandler. Hence right now you have two solutions:
>
> (1) Have two Controller
> (2) Extends Controller.pollContext() to replace instanceHandler.poll()
> with your own call (something like poll(SelectionKey)). From the
> SelectionKey, you can find the protocol by looking at SocketChannel or
> DatagramChannel.
>
>>>
>>>>
>>>> Also when execute() method of filter is called, is there any way to
>>>> figure out when this call originated from TCP or UDP.
>>>
>>> ctx.getProtocol() will return the current protocol executed.
>>>
>> I did not find this method earlier. Is this added recently? Is it
>> available in grizzly 1.5.1?
>
> Was added last Thursday :-). Yes it is in 1.5.1.
>
> Thanks
>
> -- Jeanfrancois
>
>>> Thanks
>>>
>>> -- Jeanfrancois
>>>
>>>
>>>>
>>>> Thanks,
>>>> Kshitiz
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>