Hi Jeanfrancois,
Since multiple SelectorHandler(s) scenario is designed to support
multiple protocol by one Controller, the support should be provided to
select a ProtocolChain based on protocol. I hope this support will come
soon :)
Thanks,
Kshitiz
Jeanfrancois Arcand wrote:
> Hi,
>
> Oleksiy Stashok wrote:
>> 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...
>
> But why would you register two SelectorHandler for TCP? Would it be
> better to have one per protocol?
>
> Thanks
>
> -- Jeanfrancois
>
>
>>
>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> 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
>