-
15. Re: JBM 2.0 Strict ordering via ordering groups
About performance: for each ordering group, it needs to have a sorted list to store message refs yet to be delivered, and for each message to deliver, it needs to check if the message is at the front of the list, if not, detain the delivery.
About the cluster: if there are a cluster Q on two nodes, M1 is sent to node1 and M2 to node2. If node1 dies when M1 is delivering, M1 will be moved to node2 for delivery. It need to make sure M2 will never be delivered until M1 is delivered, but who receives M1 or M2, doesn't matter. -
16. Re: JBM 2.0 Strict ordering via ordering groups
"gaohoward" wrote:
About performance: for each ordering group, it needs to have a sorted list to store message refs yet to be delivered, and for each message to deliver, it needs to check if the message is at the front of the list, if not, detain the delivery.
Huh? That's a performance penalty for your ordering group implementation not the message group implementation! I think you're getting them mixed up. I was suggesting using message groups, not ordering groups.
About the cluster: if there are a cluster Q on two nodes, M1 is sent to node1 and M2 to node2. If node1 dies when M1 is delivering, M1 will be moved to node2 for delivery. It need to make sure M2 will never be delivered until M1 is delivered, but who receives M1 or M2, doesn't matter.
Yes order is preserved on failover already in JBM 2.0