0

Hi this might be a bit of a noob question, but I can't seem to find an appropriate solution for the following use case:

On the backend we have x number of services distributed across VMs, each providing the same service (distributed replication). These services are all listening on a distributed event bus (such as Hazelcast).

When an event arrives, say GetDataA, the EventBus infrastructure sends the event to each of the back end services one at a time. If a service decides its going to process the event it does so and returns the data to the publisher of the event via the EventBus.

Once a service decides its going to process an event, then the EventBus should stop sending that event to other listeners (services), and continue routing the next event (i.e. it should be non-blocking)

So this solution requires a kind of request/response distributed event architecture running asynchronously.

Does anyone know of any scalable solutions in this space. I've looked at Hazelcast, but the event mechanism means that all listeners will get the event. I've looked at the Executor service, but this sends code to other nodes, while what I am looking for is for another single node to process the request.

Adam Davies
  • 2,742
  • 4
  • 33
  • 52

2 Answers2

3

You can do this with the Hazelcast IExecutorService. There is fine grained control on how your task is going to be send

  • send to all members
  • send to a subset of members
  • send to any member (don't care which one)
  • send to a particular member
  • send to a member that owns a particular partition.

There is also an option to use a future and you can combine the future with an async callback mechanism if you don't want to block. And the executor will not send code to a node; the code (bytecode) is already there. So you are just sending data.

Another option is to create a point to point solution if you don't want to notify everyone, but only specific member. This can be done using the IQueue.

pveentjer
  • 10,545
  • 3
  • 23
  • 40
0

For example, Bboss distributed event framework can be used to send and receive events between cluster member nodes, and can also be used to send and receive events between applications in non-cluster environments. Features of Bboss distributed event framework: Each event application Node keeps and maintains a remote event destination address book (application node address book) locally, and the address book keeps a list of valid member addresses, which is dynamically updated. Based on Jgroups multicast protocol, when a new node joins the cluster, the new node will keep its own latest address book, and its address will be automatically added to the address books of other nodes. When a node shuts down or leaves the current network for network reasons, its address will be removed from the address book of other nodes. Members are automatically discovered and updated, and bboss distributed event framework fits the mechanism of cluster members management virtually. Therefore, at the application level, the message broadcast and receiving between cluster member can be realized in a very concise and efficient way, such as the synchronous and consistent refresh of cache, the synchronous update of system data status, and so on.

Opsse
  • 1,851
  • 2
  • 22
  • 38
y yt
  • 1
  • 1
    As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Apr 01 '22 at 07:12