I'll try to explain the use case a bit further.

As said, the topic has 8 durable subscribers. On the topic, a variety of "event" messages are delivered. The subscribers already use selectors to filter out unwanted messages by event type.

This mechanism is working perfectly, but from time to time of course our business logic is faulty or data is corrupt and one or more of the subscribers (most often just one) can't process the message correctly, resulting in it being sent to the DLQ. In the message on the DLQ we can see the message properties _HQ_ORIG_ADDRESS (the topic) and _HQ_ORIG_QUEUE (the subscription). From this we can derive which of the subscribers failed in processing the message.

Now, after fixing the code, or cleaning up the data, we want to offer the message again to the topic, but only the failing subscriber should pick it up as we don't want the other subscribers to perform the same work twice.

What would be a viable strategy to achieve this?

I'll start investigating a more complex selector to see if i can get what I want from there. 

We implemented this by extending or message selectors on the messagedriven beans as Justin pointed out.

@ActivationConfigProperty(propertyName = "messageSelector",

                                        propertyValue = "... and (redeliveryProperty IS NULL OR redeliveryProperty = 'CLIENT_ID.SUBSCRIPTION_NAME)"),

In the redeliver process we then add a JMS property 'redeliverProperty' containing the value of _HQ_ORIG_QUEUE. This mechanism works like a charm.