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

John Sanda jsanda at redhat.com
Fri Jan 16 11:21:06 EST 2015


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
>> 
> 




More information about the hawkular-dev mailing list