The JMSXGroupId header Guarantees ordering of the processing of related
messages across a single queue.
nonBlockingRedelivery option controls whether on a Rollback of the session
the messages that were previously delivered and will be re-delivered should
block the delivery of new incoming messages.
I was wondering if these concepts can be used together with a single
consumer to block messages (and leave them on the queue) of the same
JMSXGroupId if there is a problem with one message, but let through messages
belonging to other JMSXGroupIds?
This isn't something I've personally tried (nor that I'm familiar with
enough to say for sure whether it would work), but it seems like it should
be possible as long as you ensure that messages that are not processable
are not moved to a DLQ no matter how many times they're retried. That seems
to be possible (see e.g.
but you'd then have to have a mechanism for migrating any message that
truly is unprocessable out of the head of the queue to allow processing to
continue. Or might you actually want to modify the content of the
unprocessable message and process the modified content before continuing?
Both of those are probably possible to do, but it's not something I've got
concrete ideas for how to do, and it will certainly depend on what your
actual needs are. I'd recommend you carefully think through your desired
behavior for edge cases such as that one before you lock yourself too
tightly to any preferred implementation, to make sure that whatever
solution you choose will meet all of your requirements rather than just
some of them.
Taking a step backwards, maybe the paradigm you're trying to use (one where
messages are sent, and there's a possibility that one might not be possible
to act upon, and then there's a need to stop the processing of later
messages) is the wrong one to use. Perhaps another approach (e.g. multiple
consumers all parse the messages and store them, with sequence numbers, in
a database, and then a separate process checks for which messages are valid
and ready for processing and then iterates that stream acting upon the
already-validated action requests) might eliminate the need to have the
ActiveMQ message broker act as a gatekeeper for preventing further action
whenever a message has a problem, as well as the need to have message
consumption occur in-order on one and only one consumer per stream.
Depending on what problems you're worried about, that may or may not be a
valid option for your needs, but it's certainly worth evaluating the full
problem and making sure that you're using the various building blocks in
your system optimally based on their respective strengths.
> I think the definition of these terms are:
> The JMSXGroupId header Guarantees ordering of the processing of related
> messages across a single queue.
> nonBlockingRedelivery option controls whether on a Rollback of the session
> the messages that were previously delivered and will be re-delivered should
> block the delivery of new incoming messages.
> I was wondering if these concepts can be used together with a single
> consumer to block messages (and leave them on the queue) of the same
> JMSXGroupId if there is a problem with one message, but let through
> belonging to other JMSXGroupIds?
> thanks in advance
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >