Hi, got into an interesting discussion where it was said that it is better to use REST for queries instead of Axon’s Query Gateway.
What if our db is down and we get thousands of GET requests piling up? If we cut public access in case of REST, all requests are dropped. But if what happens in case of Query Gateway? Are all messages removed from Axon Server / Kafka / etc? Or are they going to be stuck there taking space and time?
Hi Sam,
Firstly, would you mind elaborating why that statement was made?
I’d like to understand what angle this guy is taking; might have impact on how to steer a response.
To get to the point though, you should firstly know that the Axon QueryBus approach currently provides two implementations:
- The
SimpleQueryBus - The
AxonServerQueryBus
Thus, mind you, there is no Kafka implementation for queries (which it wouldn’t suit either, as Kafka is akin to Event distribution i.o. the Query Message Routing specifics).
When you would be utilizing the SimpleQueryBus in your application, the query would just remain within the given JVM as it’s not a distributed approach.
Any issue with handling said query would thus be thrown/bubbled up from within your Query Handler, thus returning back to the Query Dispatcher.
When it comes to the AxonServerQueryBus, if you look at the implementation you can spot that it does a query with a timeout.
This timeout ensure that your queries will not be “stuck in space and time”, but will be dropped.
At the moment, this timeout defaults to one hour, but could easily be made configurable if desired.
Hope this sheds some light on the situation Sam.
Cheers,
Steven
Thanks, Steven, that helps!
If our query model’s separate database is down, will all the “query messages” physically remain in a queue and take up space until each timeout is reached? The exact point is, I think, that if we do the same with REST and cut public access, all HTTP connections will be dropped, while with messaging, the queries will be stuck there and blow up the memory if we don’t act quickly.
If queries don’t have a destination, then they will complete (exceptionally) immediately. The sender is notified that there are no destinations for it.
If there is a destination, but it’s behaving badly, then a queue on AxonServer will fill up. I do believe (but I’d have to check) that there is a maximum. When that’s reached, senders are again notified that there is no suitable recipient to process their query.
Noting should ever fill up to infinity…