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