I've been able to reproduce the problem using your instructions on https://issues.apache.org/activemq/browse/AMQ-2135.
It looks as if Eric Chu has tracked down the cause of the issue.
We will have see if we can get an engineer to take a look at what will be required to fix this.
Thanks for looking into this. According to some of the other posts by Eric Chu, this appears to be just the entrance to a rabbit-hole of bugs. That the ActiveMQ developers appear to be basically avoiding the issue, and not even acknowledging the existence nor severity of this bug gives me pause. However, after looking at the huge number of critical bugs, both unaddressed and unassigned, in their queue, I'm not surprised that this hasn't been given priority. My guess is that most people using ActiveMQ are doing so in single broker or embedded setups for toy applications that do not have real performance or availability demands. After some more research, it looks like there are some other great options out there that solve our problems more appropriately.
Thanks for your help.
I've attached a unit testcase to https://issues.apache.org/activemq/browse/AMQ-2135 to help reproduce and debug the issue a little more easily.
FUSE Message Broker can and is most definitely used for more than "toy applications". Sabre are using it.
Thanks for creating the unit test.
Sabre sounds very impressive. Are they using version 5.x with a network of brokers topology? Are there examples of topologies/configurations that other users have that use a network of brokers in a high-throughput environment and don't have the orphaned messages problem? If someone could share a configuration that doesn't have this problem, that would be very useful.