On 5/13/09 2:34 AM, "Oleksiy Stashok" <Oleksiy.Stashok_at_Sun.COM> wrote:
>> 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 ;-)
>
>> 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
>