Thanks Jeff.
It's BLOCK policy. I haven't customized that config file at all yet (I'm running non-clustered standalone)... but it's attached so you can check anything else you're interested in.
Hey guys, thanks for looking into this.
From the discussions I've seen, it does seem that there's agreement there's a pretty critical robustness issue here (possibly more than one?), resulting in message reordering (or possibly loss) in a default HornetQ configuration, so I really hope it can be fixed soon. I'm conscious discussion of this has rather dried up since the last posts on this forum and the dev forum in July.
I'd love if it my company could make use of HornetQ for our current project, but it won't be suitable if I can't count on correct message delivery. I'd be so grateful if the next HornetQ release could fix this...
I'm not aware of any ordering issue that hasn't already been fixed.
Clebert, Jeff please advise, since you were looking into this.
If there is an issue there should be an open JIRA for it.....
I fixed a couple of other issues with Paging entering/leaving state into trunk.
There's still a case I need to investigate a case reported by Ronny Shultz (1 message out of order in 10 million) but it seems related to Diverts and Paging.
I'm doing a lot of work on paging now, so I will make sure it's all fixed for 2.2
If it's already fixed it should be a simple matter for Ben to verify this by running against TRUNK