Re: Grizzly 2.0 .unbind() , threads and filter chain
>>> I just checked .unbind() method that you added. I see that I can not
>>> specify whitch local address I want to unbind and whitch I want to
>>> leave.
>>> So to clarify, does one TCPNIOTransport supports only one binding ??
>> Right, I wasn't clear about that. You can unbind Transport and then
>> bind it to different address, but it's possible to have just one
>> active binding.
>> Though, this is interesting usecase. IMHO, we can have it
>> implemented.
>> Can I ask you to file an issue?
>
> OpenDS would needs this capability as well. I'll be on the look out
> for this
> issue ;-)
Done.
WBR,
Alexey.
>
>
>>
>>> What I see from source code (grizzly-framework-2.0.0-M1-sources.jar)
>>> we can do many bindings, each one will override serverConnection
>>> field (line : serverConnection = new TCPNIOServerConnection(this,
>>> serverSocketChannel); ). Correct me if I am wrong but is there any
>>> protection to not to override serverConnection value and to not to
>>> loose previous reference ??
>> Currently no protection. I'll add simple one, which throws
>> IllegalStateException in case, if we are already bound.
>>
>>> And again about threads. If I want to Grizzly use as low threads as
>>> it can be I should set single thread executor
>>> (Executors.newSingleThreadExecutor) to
>>> TransportFactory.getInstance().setDefaultWorkerThreadPool(...),
>>> correct ? I hope there will be no problems that it is only one
>>> thread.
>> It depends on strategy you use. If you use worker thread strategy or
>> same thread strategy - it will work. With leader-follower not.
>> Because
>> first two strategies use internal kernel thread pool to run
>> SelectorRunners (selector threads) and worker thread is used just for
>> processing I/O events, so one worker thread is ok here. Leader-
>> follower uses worker threads to run SelectorRunners (selector
>> threads)
>> and if you'll have just one worker thread - it means just one
>> selector
>> thread could be run at the time, which is issue.
>>
>>> Is selector runner started for every new transport or when ?
>> Each transport starts own selectorrunner(s), when you call
>> Transport.start(). You can specify the number of selectorrunners to
>> be
>> used by transport:
>> NIOTransport.setSelectorRunnersCount(...);
>>
>>> How many selector runners will Grizzly 2.0 start if we have for
>>> example :
>>> - three local bindings (I suppose in three different transports)
>> You can explicitly specify the number of selectorrunners for each
>> transport.
>> By default each transport initialize 2 selector runners. By default
>> one selectorrunner is used for accepting new connections, others are
>> responsible to process active connections lifecycle.
>>
>>> - three connections (made by special, forth transport, designated
>>> only for 'connection making')
>> the same as above.
>>
>> So, by default it's 2(default number of selector runners per
>> transport) * 3 (number of bound transports) + 2 (additional
>> connection
>> transport) = 8.
>> 8 threads will be busy with polling selectors. As I told for worker
>> thread and same thread strategy these 8 threads will be run in
>> internal thread pool, not worker thread pool. For leader-follower
>> strategy, these 8 threads will be taken from worker thread pool.
>>
>>>
>>> ????
>>>
>>> Is there a way to configure Grizzly 2.0 that in this case (3 local
>>> bindings, 3 connections) it will start only one selector runner and
>>> work only on one, max two threads (one for selector runner, second
>>> as a worker thread) ?
>> It could be possible, if we will implement multi binding transport,
>> which will allow to have multiple bindings on single transport.
>> Please fill the issue and I'll try to come with the solution asap.
>>
>> Again, thank you very much for the feedback!
>>
>> WBR,
>> Alexey.
>>
>>>
>>>
>>> I am waiting for response:).
>>> Thanks :),
>>> Arthur.
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>