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 -----
> On Jan 16, 2015, at 12:20 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
>
>> 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.
But aren’t you just putting in place more boiler plate with ListenableFuture?
The problem with Java futures is that obtaining the result is blocking.
ListenableFuture allows you to get the results asynchronously. We already
get the results asynchronously with JMS right? I understand the desire for
abstracting the JMS code, but I don’t what ListenableFuture buys you.