An MDB is just a normal JMS message consumer and I think there is NO possibility to direct undelivered messages for a single topic to different DLQ based on failed consumer. DLQ's are related to message adresses, but not to consuming MDB's. Chapter 21. Message Redelivery and Undelivered Messages

Ulf is right.  DLQ configuration is tied to the address, not the consumer (e.g. an MDB). 

However, I think you can get the behavior your after by using a divert to route the message to 2 different addresses (each with its own DLQ) and then have each MDB consume from the appropriate address.

Right, but then most probably an additional DLQ per individual address (=individual consumer MDB) seems to be needless. If a specific MDB is down messages simply could stay within individual address without need to send it to DLQ. This would also simplify message recovery after MDB restart.

Nevertheless  the overall planned usage approach of an additional DLQ for monitoring proper MDB activity (at least this is my assumption what you want to achieve) seems to be somehow wrong to me. Instead either you should monitor steadily increasing message count within individual address proposed by Justin as indicator for MDB failure or use any other application server management api for controlling MDB state.

To your point, a DLQ is message-centric, not consumer-centric.  It's a mechanism to deal with messages that are not processed properly regardless of the underlying problem.  It is not meant to identify a particular consumer or provide details about the nature of the failure.

Actually I think you can get what you need simply by looking at the String property "_HQ_ORIG_ADDRESS" on the messages in the DLQ.  That property indicates to what address the message was originally sent.

BTW, this is documented here.

I'm not exactly sure what you mean by, "Address of Topic or address of subscriber."

The property refers the the address where the message was originally sent.  Since multiple addresses can route to the same DLQ this property can be used to identify where the message was originally sent so it can be dealt with appropriately.

It has nothing to do with client ID.

Look at the name of the subscription to which the message was sent (i.e. the "_HQ_ORIG_QUEUE" property).  That might help you determine what subscriber failed because each subscriber gets their own subscription (i.e. queue).

However, as I indicated previously in this thread, "[a DLQ] is not meant to identify a particular consumer or provide details about the nature of the failure."