Hi,
>>> 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?
I'm thinking about scenario, when we have one Controller to listen on
several TCP ports... If we have reasons to support different protocols
on one Controller, we can have same reasons to support several instances
of single protocol.
But supporting several instances of one protocol on single Controller
could lead to other problems... Not sure. Easiest way - is to specify in
javadocs, that our Controller doesn't support several instances of one
protocol.
> 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 ?
For RoundRobin scenario - it should work fine.
WBR,
Alexey.
> 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
>