Salut,
Oleksiy Stashok wrote:
> Hi,
>
> I will just write one more time processing schema:
>>>> UDPTransport -> ProtocolChain_1 -> UDPReadFilter --> MyProtocolFilter_1
>>>> TCPTransport -> ProtocolChain_2 -> TCPReadFilter --> MyProtocolFilter_1
>>>>
>>>> where in Grizzly 1.8, we had:
>>>>
>>>> UDPTransport -> ProtocolChain_1 -> ReadFilter --> MyProtocolFilter_1
>>>> TCPTransport -> ProtocolChain_1 -> ReadFilter --> MyProtocolFilter_1
>>>
>
>
> you can see that MyProtocolFilter instance, which has common logic, is
> still shared - so no problem to share the Filter(s), which really have
> the same logic.
>
> In practice, IMHO, it's very rare situation, when single ProtocolChain
> instance must be shared among separate transports. If we can take
> Sailfin custom ProtocolFilter implementation [1], we can see a lot of
> protocol checking there... So, IMHO, this Sailfin shared protocol filter
> doesn't look very clear. IMHO it could be good idea to implement some
> AbstractMessageProtocolFilter, which will have common filter logic and
> make 3 implementations for each protocol, so there will be no need to
> perform protocol check.
>
> The same I can say about our current ReadFilter implementation [2],
> which is able to handle both TCP and UDP. Though its implementation is
> hidden from developer, you can agree with me, that it's not so easy to
> fix something there, because actually we have 2 absolutely different
> parts there, which handle different transports TCP and UDP. For me it
> doesn't look very nature to hold 2 absolutely different processing
> logics in one place.
But its makes user experience more simple :-) I agree the code is
difficult to handle, but still I do think we can refactor that class by
abstracting the transport into pluggable class (similar to what you have
proposed) and continue supporting the same scenario.
>
> At the same time, I agree, that if developer will really need to share
> some ProtocolChain related stuff - we have to make our best to make it
> as easier as possible.
Great :-) Anyway we already offer that possibility right now, e.g. One
ProtocolChain per SelectorHandler. I just want to make sure we will
still support the sharable behavior :-)
Thanks!
-- Jeanfrancois
>
> Thanks.
>
> WBR,
> Alexey.
>
> [1]
> http://fisheye5.atlassian.com/browse/sailfin/sip-stack/src/java/com/ericsson/ssa/container/MessageProcessorFilter.java?r=1.31
>
> [2]
> https://grizzly.dev.java.net/source/browse/grizzly/tags/1_8_0/modules/grizzly/src/main/java/com/sun/grizzly/filter/ReadFilter.java?annotate=1225
>
>
> my main concern about ProtocolChain sharing among separate transports -
> On Jun 19, 2008, at 2:28 , Jeanfrancois Arcand wrote:
>
>> Salut,
>>
>> Ken Cavanaugh wrote:
>>> Jeanfrancois Arcand wrote:
>>>> Salut,
>>>>
>>>> the first disagreement we had today was about the needs, in 2.0, to
>>>> have one ProtocolChain per Transport, instead of one ProtocolChain
>>>> shared amongst Transport. Alexey thinks it complexity the
>>>> programming experience when a simple Filter handle two or more
>>>> transport (like the ReadFilter, which support UDP and TCP). So in
>>>> Grizzly 2.0, the programming model would consist of:
>>>>
>>>> UDPTransport -> ProtocolChain_1 -> UDPReadFilter --> MyProtocolFilter
>>>> TCPTransport -> ProtocolChain_2 -> TCPReadFilter --> MyProtocolFilter
>>>>
>>>> where in Grizzly 1.8, we had:
>>>>
>>>> UDPTransport -> ProtocolChain_1 -> ReadFilter --> MyProtocolFilter
>>>> TCPTransport -> ProtocolChain_1 -> ReadFilter --> MyProtocolFilter
>>>>
>>>> I've objected about the proposal as I think the second approach is
>>>> much more easy to handle. Ken (correct me if I'm wrong, which is
>>>> quite possible) seemed to like the 1.8 approach as well. We stopped
>>>> the discussion and now this is time to speak :-)
>>>>
>>>> I'm still -1 on the new approach, but let's start the discussion :-)
>>>>
>>> I'd like to see the rough application code needed for each approach.
>>> I'm not really
>>> convinced either way yet as to which is the best approach.
>>
>> With 1.8.0, you do:
>>
>>> Controller controller = new Controller();
>>> controller.addSelectorHandler(new TCPSelectorHandler());
>>> controller.addSelectorHandler(new UDPSelectorHandler());
>>> controller.setProtocolChainInstanceHandler(new
>>> DefaultProtocolChainInstanceHandler() {
>>>
>>> ProtocolChain protocolChain;
>>> // Stateless ProtocolChain
>>> public ProtocolChain poll() {
>>> if(protocolChain == null) {
>>> protocolChain = new DefaultProtocolChain();
>>> protocolChain.addFilter(new ReadFilter());
>>> protocolChain.addFilter(new LogFilter());
>>> }
>>> return protocolChain;
>>> });
>>
>> No need to set the ProtocolChain for both TCP/UDPSelectorHandler, as
>> the Controller is doing it for you.
>>
>>> At some point, we presumably do something like (2.0):
>>> UDPTransport udp = transportManager.makeUDPTransport( ... ) ;
>>> TCPTransport tcp = transportManager.makeTCPTransport( ... ) ;
>>> At this point, does each transport already have a default protocol
>>> chain?
>>> Do I just need to call something like:
>>> udp.getFilterChain().addFilter( myProtocolFilter ) ;
>>> tcp.getFilterChain().addFilter( myProtocolFilter ) ;
>>
>> In 1.8.0, we allow users to create their ProtocolChain instance using
>> the ProtocolChainInstanceHandler API. So when you must create one
>> DefaultProtocolChainInstanceHandler before being able to do what you
>> want.
>>
>>> In this case, it doesn't matter whether I have one or two
>>> ProtocolChains.
>>> Is the filter chain shared across all connections in the transport?
>>
>> Depends on how the ProtocolChainInstanceHandler has been implemented,
>> e.g. stateless or statefull.
>>
>>
>>> If the filter chain has stateful elements (as in the CORBA case), we
>>> need to create a new filter chain for each new connection managed by
>>> the transport. How does that work?
>>
>> This is how it works right now.
>>
>>> Do we need something like a FilterFactory?
>>
>> Here are you talking about a ProtocolChainFactory (we cannot create
>> Filter for the user) or did I misunderstood you?
>>
>> Thanks
>>
>> -- Jeanfrancois
>>
>>> Thanks,
>>> Ken.
>>> ---------------------------------------------------------------------
>>> 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
>