[Hawkular-dev] [metrics] Looking for advice on ListenableFuture usage

John Mazzitelli mazz at redhat.com
Fri Jan 16 11:58:39 EST 2015


I have no idea if this is relevant, but in the hawkular-bus API, we now have ListenerFuture being used to support async-RPC messaging.

https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-common/src/main/java/org/hawkular/bus/common/MessageProcessor.java#L224

Send a given message to the bus via sendRPC(), tell it what type of message to expect in return, and you'll get a ListenableFuture back which you can use to obtain the response asyncyronously from the bus.

----- Original Message -----
> I don’t think it necessary to add a ticket for such a small change. I am glad
> you mentioned the REST handler code. To be honest, I am not sure. With the
> driver, I do know from experience that if you start blocking I/O threads
> with work that takes a non-trivial amount of time, you are going to start
> seeing client side timeouts. An I/O thread services multiple requests
> concurrently. For the REST handler code, we ought to investigate whether or
> not it would be better to perform the transformations on a separate thread.
> 
> > On Jan 16, 2015, at 10:48 AM, Thomas Segismont <tsegismo at redhat.com> wrote:
> > 
> > Sorry I overlooked the metrics-core code.
> > 
> > Indeed, almost every call where a ListenableFuture returned by the C*
> > driver is involved uses the overloaded version (with the metricsTasks
> > ListenableExecutor instance).
> > Should I open a JIRA for the few places where it's missing?
> > 
> > My understanding from you reply is that:
> > * all transformations on ListenableFuture returned by the C* driver should
> > happen in a thread of the metricsTasks pool
> > ==> use the overloaded version
> > * subsequent transformations may happen on the metricsTasks thread or on
> > the thread executing the rest handler code
> > ==> use the base version
> > Is that correct?
> > 
> > Thanks
> > 
> > Le 16/01/2015 14:23, John Sanda a écrit :
> >> In the metrics code, at least where a response from the C* driver is
> >> involved, the versions that take an executor is used almost everywhere.
> >> We do not want to block I/O threads doing work so in general it is best
> >> to use the overloaded versions of the methods.
> > B>
> >>> On Jan 16, 2015, at 4:47 AM, Thomas Segismont <tsegismo at redhat.com>
> >>> wrote:
> >>> 
> >>> Hi everyone,
> >>> 
> >>> I'm looking for advice on how to use Futures#transform[1] and friends
> >>> (#addCallback, #withFallback)
> >>> 
> >>> These methods all have an overloaded version which takes a JDK Executor
> >>> instance as additional argument.
> >>> 
> >>> When the base method is called, Guava will use the so-called
> >>> "sameThreadExecutor". Consequently, the code will be executed:
> >>> * by the caller thread, if the underlying Future has completed already
> >>> * otherwise, by the thread completing the underlying Future
> >>> 
> >>> When the overloaded method is called, Guava will submit tasks to the
> >>> provided executor.
> >>> 
> >>> In the metrics code right now, the base method is used almost
> >>> everywhere. Considering that in most cases it will take more time to get
> >>> the response from C* than to complete the REST Handler code, it's the
> >>> Datastax driver threads which will execute the chain of callbacks, down
> >>> to the call to javax.ws.rs.container.AsyncResponse#resume
> >>> 
> >>> Could that be a problem? I guess it's safe when callbacks only
> >>> transforms the data loaded. I'm not sure about the call to
> >>> AsyncResponse#resume.
> >>> 
> >>> Thoughts?
> >>> 
> >>> Thanks,
> >>> Thomas
> >>> 
> >>> 
> >>> [1]
> >>> http://docs.guava-libraries.googlecode.com/git-history/v16.0.1/javadoc/com/google/common/util/concurrent/Futures.html
> >>> 
> >>> _______________________________________________
> >>> Hawkular-dev mailing list
> >>> Hawkular-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> >> 
> > 
> 
> 
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>



More information about the hawkular-dev mailing list