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