It isn't per-message (unless you can ack every message as you receive it, before seeing the next one, in which case it is effectively per-message) but rather per-session acking of all unacked messages, but the intent was it would become fully per-message once JMS added individual ack, which seemed well under way in terms of discussion for inclusion in JMS 2.1: https://java.net/jira/browse/JMS_SPEC-95. Now that JMS 2.1 has been dropped from Java EE 8 the situation is less clear.
On 24 January 2017 at 14:05, Michael Lam <[email protected]> wrote: > Hi Robbie, thanks again - just as I thought I have exhausted all means of > achieving this, the mailing list shows me another possibility. I was > totally prepared to implement client-side message persistance and client > resend / recover in case nothing works - it's simple but carries too much > baggage. > > My use case needs to selectively RELEASE or ACCEPT the message based on > whether the content of the message matches an external state, so I cannot > apply the same disposition type to all unacknowledged message - or is the > disposition type evaluated on a per-message basis? If it works > per-message, I can at least use a less ugly hack :) > > > > On Tue, 24 Jan 2017 at 13:26 Michael Lam <[email protected]> wrote: > >> This topic was brought up quite a few times so I'm not here to ask for the >> feature. Instead, it is an attempt to share some workarounds, some might >> find it useful, some might not. >> >> Broker: Azure Message Bus (it could be useful for some other AMQP 1.0 >> brokers too). >> It supports a "peek lock" mode, where a receiver is given exclusive access >> to a message until it is "unlocked" (and it'll be redelivered) or >> "deleted". The broker automatically unlocks a message after the "peek lock >> timeout". >> >> In AMQP-ish speak, the broker will periodically re-enqueue a message until >> a client ACCEPTS ("deletes") or RELEASES ("unlock") it. >> >> AMQP supports individual message acks, but JMS doesn't. Now, if the >> broker fully supports JMS delayed delivery, the effect of releasing a >> single message can easily be achieved by the receiver re-publish any >> message it does not want to acknowledge, asking the broker to delay the >> enqueue. >> >> So this was the first venue I pursued. Unfortunately, I found out that >> Azure Service Bus's scheduled publishes is exposed through AMQP Management >> request/response of Azure extensions, instead of recognising the >> "x-opt-delivery-time" message annotation. Hopefully this can change. >> >> Meanwhile, after looking at the Qpid JMS Client (verison 0.20), I was >> able to devise a contained hack (ugly because it makes use of non-public >> fields and methods, but only a few lines of logic) that essentially: >> 1. wrap around a JmsConnection with a custom ProviderListener that allows >> extraction of the JmsInboundMessageDispatch envelope in onInboundMessage, >> which runs before onMessage. This allows me to store a map that goes from >> JMS Message Id to the envelopes. >> 2. instead of calling Message.acknowledge(), a call to >> JmsConnection.acknowledge(JmsInboundMessageDispatch, ACK_TYPE) is made for >> the envelope remembered in step 1 above. If it is called with RELEASE, it >> will redeliver the message right away. If it is called with ACCEPT, the >> single message is acknowledged and removed. If the calling of acknowledge >> is skipped, after the peek lock timeout, the message will be redelivered - >> so it will ack like a "RELEASE with delayed redelivery". >> >> After some testing it seems to allow me to sneak in a non-standard >> acknowledgement type. I still hope that delayed publish will one day work, >> though, understanding this hack probably won't work with the next Qpid JMS >> Client release. >> >> (I know that simply re-publish a message, even without a delay, can >> roughly simulate a message RELEASE, but having the message redelivered >> immediately is not what I'm after). >> >> It may help, or it may serve as a warning about what NOT to do with Qpid. >> >> Cheers, >> Michael >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
