charlie hunt wrote:
> 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?
>
> Maybe I'm not thinking clearly (Monday, you know) ?
>
> We have a round robin SelectorHandler which handles multiple selectors,
> right?
>
> How do we ensure keys are reregistered to the "right" SelectorHandler in
> a round robin SelectorHandler?
>
> Do I have two distinct things mixed up ?
Maybe :-) I need to take a look at Alexey implementation, but I would
think this is different as with RR, the Controller will dispatch using
another mechanism to the RR SelectorHandler implementation. But I need
to look at it as well :-)
-- Jeanfrancois
>
> charlie ...
>>
>> 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