I have a challenge where a selector is insufficient to determine the message stream of interest. I actually need to browse the messages in the queue to determine which message to process next. That would mean to implement my own message listener, and do so in a way that is compatible with JMS and JEE. Is that possible? Practical? Reasonable?
The challenge is this. A queue has multiple consumers (MDB). The consumers may be distributed across more than one machine. The first consumer will consume the first message in the queue. The second consumer will have to retrieve a key property from the first message (already being consumed). If the second message has a different key, the second consumer can consume it. If it has the same key, the second consumer needs to skip the second message and look at the third message. If the third message has a key different from the first or second message, then it can be consumed. Otherwise it also needs to be skipped. And so on.
The standard solution to use multiple queues with single consumers and messages hashed to a queue based on the key is impractical: Because it is a distributed solution that needs to support from small to large, configuration and migration on failure is a nightmare. Furthermore, the need to skip a message is rare.