Hi Nirmal,
Definitely it is a very essential and long waited feature.
But MB 3.2.0 has limitations when come to clustered environment.
1. If we use Hazelcast distributed data structure to keep the count, it is not reliable/cannot tolerate network splits and merge.
2. We have same experience with distributed message counting with Cassandra. It stores the count in quorum number of nodes but as increases and decreases happens per node very fast counts were wrong at EOD.
3. If we update count per message, number of messages to do between nodes to sync the count will be even higher, which does not work.
So after moved to RDBMS, even there if we keep the count at DB field we need to update per message, which causes too many DB writes.
If we update the count once per 1000 messages,
1. If two nodes needs to update the count, they need to coordinate and do it, otherwise there will be race conditions.
2. what if 999 messages were delivered and subscription was closed? We need to update using a timeout thread.
3. What if the node crashed all of a sudden before updating the db field? Counts will be wrong.
Due to complications like above, we still did not do the implementation. For APIM throttling etc, some error margin or delay to update will be tolerable. But for a broker counts should be accurate and should reflect the current truth I think.
This boils down to distributed counting problem (which is a research)
Thanks
_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Locked
