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

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(a)redhat.com&gt; 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(a)redhat.com&gt; >>> 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/co... >>> >>> _______________________________________________ >>> Hawkular-dev mailing list >>> Hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev