[Hawkular-dev] [metrics] Looking for advice on ListenableFuture usage
John Sanda
jsanda at redhat.com
Fri Jan 16 12:08:35 EST 2015
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
More information about the hawkular-dev
mailing list