Hi Kshitiz,
Kshitiz Saxena wrote:
> 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 :)
he idea behind having one Controller and several SelectorHandler was to
make sure UDP/TCP and TLS can be handled by a single Controller, and all
the other Handler (including the ProtocolChain) will be shared amongst
SelectorHandler (to avoid several Thread pool as an example).
Feed me with more info about why having two Controller is not a good
ideas :-)
Thanks
-- Jeanfrancois
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>