About IDistributedEventHandler

[NickCc6]

Hi,
I was working with IDistributedEventHandler in my code and ran into this thing. My setup splits the work between a Server and a Client app.

Here's what's weird: If I start just the ​​Server​​ by itself (without the Client running), then whenever the Server uses IDistributedEventHandler.PublishAsync to send something out, the messages end up ​​empty​​ in RabbitMQ. Like, there's nothing useful in them.

​​But​​, if I start ​​both​​ the Server ​​and​​ the Client together, everything works perfectly fine – messages go through normally.

So my big question is: ​​Do I have to start the Client before the Server?​​ And what happens if the Client starts later, or crashes and has to restart? Does that mean ​​any messages the Server sends out while the Client is down or starting late are just... gone forever?​

[maliming]

Both the server and the client need to start, but there's no specific order they must follow.

The server will send messages to the RabbitMQ server, and the client will consume the messages once it connects to the RabbitMQ.

[NickCc6]

Hey, thanks for getting back to me. But when I tested this, I found it doesn't actually work that way. If I start the server without starting the client, any messages sent during that time just ​​got lost​​.

I tried to find the problem from the source code, and I found that if the server does not implement IDistributedEvent Handler, then Exchange and Queue will not have a routing key
But strangely, if the client starts successfully and Exchange and Queue are also bound to the routekey, the client goes offline and the server sends a message. At this time, the Total quantity of Queue in RabbitMQ does not change
This makes me a bit confused

What I'm trying to achieve is:
If the client isn't running, messages should ​​stay in RabbitMQ​​.
Then, ​​when the client comes online later​​, it should receive those messages.

If you have time, you can take a look at my demo
demo

Thanks

[NickCc6]

After new tests, I'm convinced that IDistributedEventHandler fails to meet the requirements.

Moreover, a new issue has been found: when the server and client are deployed in a distributed manner, messages cannot be guaranteed to be delivered to the client via IDistributedEventHandler.PublishAsync, which is unacceptable in my business scenario.

I checked the source code and found that ABP always has a Consumer resident during startup. This causes the server to receive messages even if it doesn't need to consume them. Additionally, the source code logic is that if the consumer doesn't encounter errors during consumption, it defaults to a successful consumption. This is very problematic for me, as it results in the client not receiving all messages.

I'm not sure if I'm using it incorrectly or if it's designed this way. I can only look for another solution.

[NickCc6]

I solved this problem by using two different Queues for the client and the server, which well meets my requirements.