Jeanfrancois Arcand wrote:
> 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.
I think that might be a good idea.
But, before we push the "named 2.0" source out there as a "sandbox" or
"experimental" area, I should make sure the lawyers wouldn't come
running after me.
In other words, I should go look at the sources of the "named 2.0" code
and make sure it has the proper source headers in it. :-)
Then, we can decide where to push that code too.
charlie ...
>
> -- 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
>
> ---------------------------------------------------------------------
> 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/>