@ElanHasson This name is used to distinguish different streams,It is possible that more than one observer grain uses one,But it's not a good name.
What do you mean?
Shouldn't each consumer have it's own queue?
Producer publishes single event
Broker duplicates the event across multiple queues based on the routing key
In fact if they share the same group, different consumers won't get the event
At least from the rabbit perspective.
The code may deliver the same event off the queue to multiple subscribers even though they don't have corresponding queues.
I'm still digging through the logic around message delivery.
Last night I was exploring archives, very nice btw
That also kinda concerns me as different observers could be activated on different silos.
In case the message is dequeued on silo a, but observer is activated on silo b
Perhaps that what the synchronize observers does..still reading code
We'd want the placement of the observer to be on the same silo of the queue reader for that specific observer. (Locality)
And of course if the grain is 100% reentrant we may employ a strategy where the queue is consumed once per silo and delivered to locally activated grains
Dunno, have to finish reading code
Ray is not using 'Broker duplicates' thing. As you could see on the screenshot you had, features is marked 'D' , not faout. Ray is using C# code to connect publisher and consumer.
Actually, it is better for performance to use direct but faout in rabbit mq. That is why direct queue comes up. Performance first is the almost first consideration about Ray.
if you want to use some faout queue in rabbit mq . maybe you`d better to use some event bus things.
@ElanHasson In this design, it is considered that some consumers with similar processing performance can use the same queue.Consumers with different processing performance use different queues to prevent the degradation of processing performance caused by mutual interference.
A queue is processing events of the same type but with different actor id, so it must go through the gateway of Orleans, or it will lose the ability of automatic load balancing.
That's how I understood as well. The routing in the C# code helps in that.
@ElanHasson Recently, I repeatedly read the code and found that many designs were unreasonable. I started a new experimental project, which may be better.
I think i saw that @luohuazhiyu
My suggestion is to decrease the complexity, and model it for a ES + CQRS + DDD approach.
@ElanHasson Are there more detailed steps? My engineering level is not very good.
The Producers should be DDD Aggregates that manage state and output 0 or more events. Similar to what Ray does now.
Use Orleans Streams for incoming events from the broker.