Publisher confirm support

[feelyou]

We are planning migrating from ActiveMQ to RabbitMQ. We need the at-least-once delivery guarantee and the response time is critical to our application. So we want to use publisher confirm extension but it is not supported in JMS client.
I want to know why this feature is not an option in JMS client. Do you consider the JMS specification compliance or other policy? If I fork it and add the feature to RMQConnection#createChannel, will there be some unknown problems?
Thanks in advance!

[acogoluegnes]

Publisher confirms would be an interesting feature to add, but it is asynchronous by nature and the JMS API does not provide a callback after publishing.

One possible integration without extending the JMS API would be to add a flag to enable publisher confirms and block until confirm arrives for each outbound message. This would be transparent for JMS applications but would perform terribly (don't expect more than a few 100's of messages per second, even less, depending on the scenario). Nevertheless it could work for applications that favor API compliance and reliability other throughput.

Another integration would be to implement the publisher confirms asynchronous API inside the JMS client, based on the AMQP client one. Performance would be better than with the first option, but this would be super leaky and terrible in terms of API compliance. I'd rather suggest using directly the AMQP client instead of trying to push its API inside inside the JMS client.

[lukebakken]

I'd rather suggest using directly the AMQP client instead of trying to push its API inside inside the JMS client

👍 to this.

[feelyou]

@acogoluegnes Thank you for your reply.
IMHO, using publisher confirms and a default callback with empty methods has same effect to automatic confirms. Maybe there could be some extension point for application developers to build thire own implementions of ConfirmListener while not interfering JMS spec.
If there's any misunderstand please point it to me.
Thanks a lot!

[michaelklishin]

An API extension is what we will investigate. Unfortunately retrofitting a client to do what it was not meant to do can end up with sub-optimal results. Hence the suggestion to use the client that already has publisher confirm support.

[feelyou]

@michaelklishin Thanks for the explanation.
Just because RabbitMQ has better response time, we consider to migrate from ActiveMQ to RabbitMQ. Response time along with at-lease-once guarantee are more concerned than throughput. And if we use AMQP publisher with JMS consumer, it would be much dangerous than modifying rabbit-jms-client.

In the perspective of standard and public library, maybe it's not a good option to support publisher confirms. I think 'fire and forgot' has little difference to 'recieve confirm and ignore', so I want to fork it and use it privately, is there any bad influence?

[acogoluegnes]

RMQConnectionFactory could have a ConfirmListener property like the following one:

interface ConfirmListener {

  void handleAck(Message message);

  void handleNack(Message message);

}

This is different from the AMQP Java client (no sequence number, no multiple flag), but the JMS client would handle the difference, making the developer's like easier in this case. This is basically what Reactor RabbitMQ does.

@michaelklishin @feelyou WDYT?

[michaelklishin]

@acogoluegnes if it works for Reactor RabbitMQ, I'd say let's do it.

[feelyou]

@acogoluegnes Thanks! I think rabbitmq-jms-client shoud do sufficent but as less as possible work, how about just add addConfirmListener method to RMQConnectionFactory(using existing ConfirmListener interface inside rabbitmq-java-client) and leave other responsibilities to application developer?

[acogoluegnes]

@feelyou The AMQP client ConfirmListener methods refer to the publishing sequence number (aka delivery tag), which has no JMS equivalent. Without this there's no way to correlate the publisher confirm to the original message.

What I'm suggesting with this new interface is to abstract this away from the user of the JMS client.

[acogoluegnes]

I forgot to mention in my proposal that if the ConfirmListener is not set, the underlying AMQP channels will never be set to use publisher confirms, making this feature an opt-in, without any impact if it's not turned on.

[feelyou]

@acogoluegnes Got it, thanks!