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

[John Mazzitelli]

> I haven’t looked at the code too closely yet, but why the need for
> ListenableFuture to get the response from the bus? JMS/messaging is already
> asynchronous.

In the RPC-like use-case, I send a message on the bus, and I expect to get a response back from that message. This API helps hide the annoying JMS boiler-plate code you'd have to write to do that RPC-like functionality.

----- Original Message -----
> I haven’t looked at the code too closely yet, but why the need for
> ListenableFuture to get the response from the bus? JMS/messaging is already
> asynchronous.
> 
> > On Jan 16, 2015, at 11:58 AM, John Mazzitelli <mazz at redhat.com> wrote:
> > 
> > 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
> >> 
> > 
> > _______________________________________________
> > hawkular-dev mailing list
> > hawkular-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> 
>