Jeanfrancois Arcand wrote:
> 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 :-)
I think you're right ... I think the RR SelectorHandler stuff is handled
differently. I should go back and look at what I did last summer / fall
when doing a first implementation of RR SelectorHandler.
charlie ...
>
> -- 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>