FutureCallback API - wait for completion

Imported from Google Groups
#1

When dispatching a command, one way to wait for command completion before continuing, is to use a FutureCallback and call it’s get() method right?
I’ve seen in a couple of Allard’s post’s that he thinks calling get() is kind of ugly - I totally agree on this. Especially in cases where I only want to wait, I’m not interested in the result (so get doesn’t make any sense here).
Looking at the FutureCallback API I see awaitCompletion(long timeout, TimeUnit unit). This method is prettier, however there’s no no-args awaitCompletion(). What’s the reason for this? I would rather use this one than get()…

/Alex

#2

Hi Alex,

you may want to consider using the CommandGateway concept instead. The command gateway provides a customizable API towards the command bus, where you define the API yourself. Based on that API, Axon will detect whether it should block waiting for a result, or perform a fire-and-forget.
Check out the reference guide in chapter 3.1 (http://www.axonframework.org/docs/2.1/command-handling.html#d5e220) and especially 3.1.2.

Regarding the awaitCompletion method, you never really want to wait forever. Forever takes a long time. I’m still waiting for it to come ;-).

I have to make this remark: seriously consider preventing blocking altogether, and use a callback instead. Of course, this requires your other API’s to allow asynchronous behavior (such as Servlet 3 async, if it came from a web request).

Cheers,

Allard

#3

Hi Allard,

Yes, I’m using CommandGateway with my own API. But some of the command methods are non-blocking by API definition (void return and no checked exceptions). I don’t want the gateway clients to assume whether the command execution is blocking or not. But they can assume it might be non-blocking. So the clients can use a callback for these methods, and now clients can choose to wait or not. Some clients wants to wait, and FWIU, the best way to do this is to use a FutureCallback and call get(), hence my question about the API.

/alex

#4

Hi Alex,

did you consider the option to create methods with timeout parameters (a long and a TimeUnit as last two parameter)? Even if the method has a void return value and declares no exceptions, it will block for the given amount of time until a value was returned. A failure would then be thrown as a RuntimeException, while success would mean nothing happend, except for the blocking to end.
Alternatively, you can declare an @Timeout annotation on your method.

Cheers,

Allard