users@grizzly.java.net

Re: leader-follower, and ReadController in 1.9.16-SNAPSHOT

From: Jeanfrancois Arcand <Jeanfrancois.Arcand_at_Sun.COM>
Date: Tue, 12 May 2009 17:56:25 -0400

Salut,

John Franey wrote:
> Hi,
>
> I'm trying to get a handle on how threads are being used in
> 1.9.16-SNAPSHOT (svn r3170). I currently have two areas of outstanding
> questions.
>
> 1) I see leader-follower strategy. When in use, a worker thread from
> the controller's threadpool is used for the SelectorHandlerRunner. When
> a selected event occurs, delegateToWorker branch of
> SelectorHandler.handleSelectedKey, the current thread requests another
> thread to become the selector thread, and handles the key processing
> itself, returning itself to the thread pool on completion.

So far so good.

This is
> different from a strategy where the selector thread requests another
> thread to do the key processing, and retains the role as selector
> thread. Is this correctt?

Yes.

   Is this strategy effective if there is more
> than one selector key (event) to process? or, under what conditions is
> this strategy ineffective/effective?

Usually leader/follower gives better results, but our measurement didn't
show a boost like we were expected. We got a ~4% boost.



>
> 2) I see that Controller.autoConfigure sizes readThreadsCount (by the
> number of processors). This value is used later in Controller.start to
> create a RoundRobinSelectorHandler; for each of readThreadsCount, a
> ReadContoller is created. When acceptInterest occurs,
> RoundRobinSelectorHandler will pick one of the ReadControllers and
> assign the selected channel to it.

Yes.

  Each ReadController runs its own
> SelectorHandler thread, and so, selection work is distributed across a
> group of threads (sized by the number of processors). It looks like
> this action of distributing selection across threads will only be
> activated onAcceptInterest, and in cases where a server does not bind,
> this won't occur. Is that correct?

Yes. And the performance out-of-the-box is 50% higher.

  In absence of onAcceptInterest
> callbacks (no binding), can selection work be distributed across threads?

Can you elaborate about this scenario?

Thanks

-- Jeanfrancois



>
> Thanks,
> John
>