Reply to a request through a queue using hazelcast

I wonder if I can ask for a reply:

>1 hazelcast instance / member (central point) > 1 application that uses hazelcast client to send requests through the queue > 1 application. Use hazelcast client to wait for requests to enter the queue

The first application also receives a response from another queue published by the second application

Is this a good way? Or do you think there is a better solution?

thank you!

Solution

Over the past few days, I have also used hazel cast queues to communicate between different processes on different machines

My main goal is

>"One to many" communication and how many people guarantee to reply > "one to one" communication one-way > "one to one" communication, and answer within a certain time

In conclusion, I abandoned this method today for the following reasons:

>Many complex codes, including executor services, labels, runnables, interruptedexception, shutdown handling, hazelcast transaction, etc. > when the life of the receiver is shorter than that of the sender, hang messages in the case of "one-to-one" communication > If I kill some cluster members at the right time, I will lose messages > all cluster members must be able to deserialize messages, Because it can be stored anywhere Therefore, for some clients and services, messages cannot be "specific"

I switch to a simpler method:

>All "services" use the hazelcast cluster member UUID as the key to register themselves in the Multimap ("service registry") Each entry contains some meta information, such as service identifier, loading factor, startup time, host, PID, etc. > the client selects the UUID of one of the entries in the Multimap and uses the distributedtask (distributed executor service) to call the service for the selected specific cluster members, And you can choose to get the reply (timely) > only the service client and service must have a specific distributedtask implementation in their classpath, and all other cluster members will not be disturbed > the client can easily find the dead entry in the service registry: if they can't see the cluster member with a specific UUID (hazelcastinstance. Getcluster() Getmembers()), the service may die unexpectedly Then, the client can select the "active" entry, the entry with less load factor, retry in the case of idempotent service, etc

Using the second method (such as timeout or cancel task), programming becomes very simple and powerful, not to mention the code to be maintained

I hope this can help!