Possible problem with large number of addresses and wildcard queues

[kgregory]

Our application sends messages to addresses of the form "APP.VERSION.X.Y", where there are approximately 50 different values for X and 50,000 different values for Y. The listener listens to the address "APP.VERSION.X.*". Occasionally the receiver will start receiving messages where getAddress() returns the wildcard:

message received containing wildcard: predictive.1_4.121.*

         message ID:       40419858

         original address: null

         delivery count:   1

         timestamp:        1310568295561

message received containing wildcard: predictive.1_4.121.*

         message ID:       40549907

         original address: null

         delivery count:   1

         timestamp:        1310568392092

In both of these cases, the address should have been "predictive.1_4.121.121+11332". It appears to affect specific addresses repeatedly; there should be several thousand messages per minute where the X value is 121, but we only see the error where the Y value is 121+11332. Similar problems happen for other X values. It doesn't matter whether we wildcard with "#" or "*".

If we shut down and restart the consumer, the same addresses have problems. If we shutdown and restart the producer, it will be different addresses.

We have not yet tried to replicate with a SSCEP, but were hoping that you could provide some insight before we do that.

[ataylor]

Im a bit confused as to your issue, if you provide a simpl; etest we will take a look

[kgregory]

I was able to reproduce with a small test program, and have created a bug report: https://issues.jboss.org/browse/HORNETQ-740

I'd be very surprised if I was the first person to run into this, so am assuming that I'm merely using the API incorrectly (perhaps I shouldn't be calling ClientMessage.getAddress() in the consumer).

It does seem that all messages are delivered, so in our real-world app we can work-around.