[infinispan-dev] Threadpools in a large cluster

[Dan Berindei]

On Thu, Feb 7, 2013 at 12:43 PM, Bela Ban <bban at redhat.com> wrote:

>
> On 2/7/13 11:09 AM, Dan Berindei wrote:
> >
> >
> >     A few changes I have in mind (need to think about it more):
> >
> >     - I want to leave the existing RequestHandler interface in place, so
> >     current implementation continue to work
> >     - There will be a new AsyncRequestHandler interface (possibly
> >     extending
> >     RequestHandler, so an implementation can decide to implement
> >     both). The
> >     RequestCorrelator needs to have either request_handler or
> >     async_request_handler set. If the former is set, the logic is
> >     unchanged.
> >     If the latter is set I'll invoke the async dispatching code
> >
> >     - AsyncRequestHandler will look similar to the following:
> >     void handle(Message request, Handback hb, boolean requires_response)
> >     throws Throwable;
> >     - Handback is an interface, and its impl contains header information
> >     (e.g. request ID)
> >     - Handback has a sendReply(Object reply, boolean is_exception) method
> >     which sends a response (or exception) back to the caller
> >
> >
> > +1 for a new interface. TBH I hadn't read the RequestCorrelator code,
> > so I had assumed it was already asynchronous, and only RpcDispatcher
> > was synchronous.
>
>
> Nope, unfortunately not.
>
>
>

> >
> > I'm not so sure about the Handback name, how about calling it Response
> > instead?
>
>
> It *is* actually called Response (can you read my mind?) :-)
>
>
Nice :)


> >
> >     - When requires_response is false, the AsyncRequestHandler doesn't
> >     need to invoke sendReply()
> >
> >
> > I think this should be the other way around: when requires_response is
> > true, the AsyncRequestHandler *can* invoke sendReply(), but is not
> > required to (the call will just time out on the caller node); when
> > requires_response is false, invoking sendReply() should throw an
> > exception.
>
>
> The way I actually implemented it this morning is to omit the boolean
> parameter altogether:
> void handle(Message request, Response response) throws Exception;
>
> Response is null for async requests.
>
>
Sounds good.


>
>
>
>
> >
> >
> >     - Message batching
> >     - The above interfaces need to take message batching into account,
> >     e.g.
> >     the ability to handle multiple requests concurrently (if they
> >     don't need
> >     to be executed sequentially)
> >
> >
> > You mean handle() is still going to be called once for each request,
> > but second handle() call won't necessarily wait for the first
> > message's sendReply() call?
>
> Yes. I was thinking of adding a second method to the interface, which
> has a message batch as parameter. However, we'd also have to pass in an
> array of Response objects and it looked a bit clumsy.
>
>
Agree, it would look quite clumsy.


> >
> > Is this going to apply only to OOB messages, or to regular messages as
> > well? I think I'd prefer it if it only applied to OOB messages,
> > otherwise we'd have to implement our own ordering for regular/async
> > commands.
>
> No, I think it'll apply to all messages. A simple implementation could
> dispatch OOB messages to the thread pool, as they don't need to be
> ordered. Regular messages could be added to a queue where they are
> processed sequentially by a *single* thread. Pedro does implement
> ordering based on transactions (see his prev email), and I think there
> are some other good use cases for regular messages. I think one thing
> that could be done for regular messages is to implement something like
> SCOPE (remember ?) for async RPCs: updates to different web sessions
> could be processed concurrently, only updates to the *same* session
> would have to be ordered.
>
>
Yeah, I agree implementing the regular message ordering ourselves would
give us a little more room for optimizations. But it would make our part
more complicated, too. Well, not for Total Ordering, because Pedro already
implemented it, but for our regular async scenarios we'd need to add a
thread pool (we want to allow 2 threads from different sources to access
different keys at the same time).



> This API is not in stone, we can always change it. Once I'm done with
> this and have batching II implemented, plus some other JIRAs, I'll ping
> you guys and we should have a meeting discussing
> - Async invocation API
> - Message batching (also in conjunction with the above)
> - Message bundling and OOB / DONT_BUNDLE; bundling of OOB messages
>
> --
> Bela Ban, JGroups lead (http://www.jgroups.org)
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130207/c796b2ad/attachment.html