charlie hunt wrote:
> 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.
I would really think we should push out the "named 2.0" version to the
java.net workspace. What we can propose is a sandbox folder under
grizzly/sandbox where we can put experimental code that will eventually
be part of the distribution there. Things like the jetty-on-15, "named
2.0", load balancer/tunnel can probably go under the folder.
What do you think? I'm +1 to send a proposal to this list if people
think this is a good idea.
-- Jeanfrancois
>
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net