Clarify intended uses for AsyncRabbitTemplate. about spring-amqp HOT 9 CLOSED

What makes you think the send will block? RabbitMQ is async - although I guess it will block if the broker can't keep up and applies flow control to the connection.

It was not the intent of this template to "ignore" conditions when the broker is in a sad state, just to avoid blocking your thread while waiting for a reply.

from spring-amqp.

To confirm @garyrussell 's comment:

 /**
     * Publish a message.
     *
     * Invocations of <code>Channel#basicPublish</code> will eventually block if a
     * <a href="http://www.rabbitmq.com/alarms.html">resource-driven alarm</a> is in effect.
     *
     ....
     */
    void basicPublish(String exchange, String routingKey, boolean mandatory, BasicProperties props, byte[] body)

from spring-amqp.

@garyrussell @artembilan thanks for the quick response. Sorry, by blocking I meant writing to the socket's OutputStream. I'm in a situation where I'd like to send but not block (not do I/O) on the thread sending the message. Do you think that would be a good case for using @Async?

from spring-amqp.

Well, Spring AMQP since version 1.7 supports the latest RabbitMQ client with a NIO option: https://www.rabbitmq.com/blog/2016/11/24/rabbitmq-java-client-4-0-is-released/

Since it isn't there by default you should configure your RabbitConnectionFactoryBean for the setUseNio(true).
No reason to overhead with the @Async - the Framework will do the stuff for you!

from spring-amqp.

Interesting ok. Maybe if I could be more specific, if I want to send a message during a web request, but I'd rather not block the request, is that the route you'd take (NIO)? I feel like what I need is a way to 'queue' the message, with a separate thread pulling off the queue and sending it. Does that sound like a weird approach? An added constraint is that the message must be guaranteed delivered (thinking publisher confirms.)

from spring-amqp.

It will be queued in the NIO loop anyway, but doing that manually you are losing context of the RabbitTemplate. It would be much complicated for your to get a reply from there.

We are just sharing with you an info how it works.
Everything rest is your decision.

In the future consider to ask similar question on StackOverflow.
GH (and JIRA) is for bugs and fuature requests.

from spring-amqp.

Yeah, apologies I got off track, thanks for the response.

from spring-amqp.

I feel like what I need is a way to 'queue' the message, with a separate thread pulling off the queue and sending it.

An added constraint is that the message must be guaranteed delivered (thinking publisher confirms.

Those two requirements are competing. If you hand off to a volatile queue, you can be sure you will lose messages in the event of a server failure.

Generally, unless you have a congested network/broker, the send won't block; I fear you are worrying about a situation that is unlikely to occur and, if it does, you have bigger problems than a slow HTTP response.

from spring-amqp.

Those two requirements are competing. If you hand off to a volatile queue, you can be sure you will lose messages in the event of a server failure.

Yeah, good point.

Generally, unless you have a congested network/broker, the send won't block;

Hmm, I don't completely agree. At the end of the day we're talking about writing to a socket. I'd love to assume networking issues won't happen. I'd prefer not to ignore those cases though.

Bringing it back to the original issue, when I saw Async I immediately thought 'run this in the background.' But as you mentioned, this was not the intent.

from spring-amqp.