Hi,
IMO it's always trade-off, if we don't have a lot of connects, then it
means ACCEPT selector-thread(s) will do nothing, even though others
might be busy with READ/WRITE processing.
In Grizzly 1.9 we used to separate accept- and read/write-
selector-threads, and if you think it would make sense for your usecase
- please file the issue, it should be pretty easy to implement another
ConnectionDistribution.
Any contributions are always welcome.
Thanks.
WBR,
Alexey.
On 06/08/2011 04:32 AM, yangjun2 wrote:
> @Override
> public GrizzlyFuture<RegisterChannelResult> registerChannelAsync(
> final SelectableChannel channel, final int interestOps,
> final Object attachment,
> final CompletionHandler<RegisterChannelResult>
> completionHandler)
> throws IOException {
> final SelectorRunner runner = getSelectorRunner();
>
> return transport.getSelectorHandler().registerChannelAsync(
> runner, channel, interestOps, attachment,
> completionHandler);
> }
>
> private SelectorRunner getSelectorRunner() {
> final SelectorRunner[] runners = getTransportSelectorRunners();
> final int index = counter.getAndIncrement() % runners.length;
>
> return runners[index];
> }
> }
>
>
> When many client current connection, grizzly all SeclectorRunner process
> ACCEPT operation , and not one could process READ/WRITE operation.
> How to do it?
>
> --
> View this message in context: http://grizzly.1045725.n5.nabble.com/RoundRobinConnectionDistributor-why-not-distinguish-ACCEPT-operation-from-READ-WRITE-operation-tp4464523p4464523.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.