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

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

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 ----- > > > On Jan 16, 2015, at 11:58 AM, John Mazzitelli <mazz(a)redhat.com&gt; 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/... > > > > 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(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 > >> > > > > _______________________________________________ > > hawkular-dev mailing list > > hawkular-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hawkular-dev > >

I find trying to write the same functionality in straight JMS will show the usefulness of MessageProcessor.sendRPC. Again, this is to support RPC-like functionality - which isn't trival in JMS (as opposed to fire-and-forget, 1-way messaging). You wouldn't use this sendRPC if you are just shooting a message on the bus and not expecting a direct response to that message. ----- Original Message -----

I originally was using Future, and you told me I should use google's ListenableFuture instead :) I don't think Jay is using it in his alerts stuff, so I can only point you to the unit tests that test it: see testSendRPC and testSendRPCAndUseListenableFuture in: https://github.com/hawkular/hawkular-bus/blob/master/hawkular-bus-test-co... They send a "SpecificMessage" and expect a response back (where the message that comes back in the response merely echoes back to the caller the message that was originally sent in that "SpecificMessage" prefixed with the string "RESPONSE:"). ----- Original Message -----