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?
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
>