0

I'm implementing an Domain Event infrastructure, but the project doesn't allow any messaging infra(financial services client) so found an alternative in Hazelcast Topics and ExecutorService,

But the problem is when running in cluster the message shall be delivered to listeners which is going to be running in cluster, so for a cluster of 2, we have same listener running in 2 jvm, and message consume twice and acted upon, suppose the Domain event is supposed to perform some non idempotent operation like credit some loyalty points, unless I explicitly maintain a trace of domain event acted upon and check against that everytime I receive an event, I will end up crediting it twice, "any suggestion implementing this without having to write those boiler plates possibly at the infralayer", or is there a known patter for such implementation.

Edit: Meanwhile I'm also evaluating Hazelcast ExecutorService as suggested Here

Community
  • 1
  • 1
Somasundaram Sekar
  • 5,244
  • 6
  • 43
  • 85

1 Answers1

1

The use case you described can be solved by using Hazelcast's Queues instead of Topics. The main reason to use topics is if you are interested that multiple (possibly independent) consumers get the same message. Your requirement sounds like you are interested that only one of the consumers gets the message, and that's what queues are for, see the Hazelcast documentation for Queues.

svenpanko
  • 180
  • 8
  • May I try to expand the requirement further, Topic has been chosen because the message has to be delivered to multiple subscribers, but if a subscriber is running in multiple jvm, only one instance of the subscriber should process the message. – Somasundaram Sekar Apr 19 '16 at 11:59
  • In this case you can solve this problem in many ways with external locking, i.e. you have to make sure that the messages you process are not currently processed elsewhere. One solution might be to use a distributed map that all listeners have access to, in combination with a distributed lock. Every listener acquires the lock, checks if the message has already been processed or is currently processed (message id in the map) and if not, it places an entry in the map (IN_PROCESS or something similar). Then the listener releases the lock and depending on the map-state he processes it or not. – svenpanko Apr 20 '16 at 14:32
  • And after successful processing, the respective listener acquires the lock again, updates the map entry to PROCESSED or similar and that's it. The only thing you have to make sure is that at some point in time the entries in your map expire, otherwise you will run out of memory ;) – svenpanko Apr 20 '16 at 14:35
  • The challenge here is the Message Id. For big messaging systems, there is no concept of a unique id that can be used to identify a particular message. ( say MQTT ) . – NishM Mar 21 '18 at 21:15