I don't think that would work well, since I am buidling a testbox that
represents many parties, each with a different 'protocol stack' (most are
tcp/ip, some udp; some use http, some not; some use ssl, some not; ...), and
in TCPNIOTransport.start I see that for every transport a number of
SelectorRunners is started. As it was my plan to use nio to limit the number
of threads, this seems not the way to go. In my opinion it should be
possible to set a FilterChain for every server connection (not necessarily
direct), but not a threadpool like you also say, since the threads should be
just executors. In my opinion there could be just one pool of threads,
executing whatever needs to be done (read, write, processTask, ...) for
whatever client request.
Oleksiy Stashok wrote:
>
> Hi,
>
>> The TCPNIOTransport uses a SingletonFilterChainFactory:
>>
>> ...
>> PatternFilterChainFactory patternFactory =
>> new SingletonFilterChainFactory();
>> FilterChain filterChain = new
>> DefaultFilterChain(patternFactory);
>> patternFactory.setFilterChainPattern(filterChain);
>>
>> filterChainFactory = patternFactory;
>> ...
>>
>> which makes it 'hard' to create a multi-bind server with different
>> FilterChain's. I now use this for every ServerConnection:
>>
>> PatternFilterChainFactory factory = new SingletonFilterChainFactory();
>> filterChain = new DefaultFilterChain(factory);
>> ...
>>
>> Which is against the idea behind a factory.
> I just updated FilterChain implementations, so it doesn't require
> Factory to be passed in constructor.
>
>>
>> Of course I could create another Factory that implements
>> FilterChainFactory,
>> but I think this should be in the framework itself. But not through
>> the
>> TCPNIOTransport class!, since the processor is related to the
>> ServerConnection and not to the Transport.
>>
>> So it would be better, in my opinion, if something like this would be
>> possible:
>>
>> Connection serverConnection = m_transport.bind(sAddress, iPort);
>> ...FilterChainFactory factory =
>> serverConnection.getFilterChainFactory(); //
>> anything, but NOT a SingletonFilterChainFactory!
>> ...FilterChain filterChain = factory.create();
>> --
> I see your idea, but as I said in one of prev. mails, I see
> ServerConnection as just subclass of Connection and not sure about
> idea of having filter chains or thread pools to be set per
> ServerConnection. In this case, IMHO, it could make sense to use
> separate transport instance. What do you think?
>
> WBR,
> Alexey.
>
>
>> View this message in context:
>> http://www.nabble.com/Grizzly-2.0-M3%3A-multi-binding-requires-other-than-SingletonFilterChainFactory-tp23939701p23939701.html
>> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
>
--
View this message in context: http://www.nabble.com/Grizzly-2.0-M3%3A-multi-binding-requires-other-than-SingletonFilterChainFactory-tp23939701p24286156.html
Sent from the Grizzly - Users mailing list archive at Nabble.com.