Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 08 2020 08:55
    u-less closed #81
  • Nov 08 2020 08:55
    u-less closed #59
  • Nov 08 2020 08:55
    u-less closed #58
  • Nov 08 2020 08:55
    u-less closed #43
  • Nov 08 2020 08:55

    dependabot[bot] on nuget

    (compare)

  • Nov 08 2020 08:55
    dependabot[bot] commented #112
  • Nov 08 2020 08:55

    dependabot[bot] on nuget

    (compare)

  • Nov 08 2020 08:55

    dependabot[bot] on nuget

    (compare)

  • Nov 08 2020 08:55

    dependabot[bot] on nuget

    (compare)

  • Nov 08 2020 08:55

    dependabot[bot] on nuget

    (compare)

  • Nov 08 2020 08:55

    dependabot[bot] on nuget

    (compare)

  • Nov 08 2020 08:55
    u-less closed #112
  • Nov 08 2020 08:55

    dependabot[bot] on nuget

    (compare)

  • Nov 08 2020 08:55

    dependabot[bot] on nuget

    (compare)

  • Nov 08 2020 08:55

    dependabot[bot] on nuget

    (compare)

  • Nov 08 2020 08:55

    dependabot[bot] on nuget

    (compare)

  • Nov 08 2020 08:55
    dependabot[bot] commented #111
  • Nov 08 2020 08:55
    dependabot[bot] commented #110
  • Nov 08 2020 08:55
    dependabot[bot] commented #109
  • Nov 08 2020 08:55
    dependabot[bot] commented #108
Elan Hasson
@ElanHasson
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
Newbe36524
@newbe36524
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.
nless
@luohuazhiyu
@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.
nless
@luohuazhiyu
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.
Elan Hasson
@ElanHasson
That's how I understood as well. The routing in the C# code helps in that.
nless
@luohuazhiyu
@ElanHasson Recently, I repeatedly read the code and found that many designs were unreasonable. I started a new experimental project, which may be better.
Elan Hasson
@ElanHasson
I think i saw that @luohuazhiyu
My suggestion is to decrease the complexity, and model it for a ES + CQRS + DDD approach.
nless
@luohuazhiyu
@ElanHasson Are there more detailed steps? My engineering level is not very good.
Elan Hasson
@ElanHasson
sure.
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.
That is the book.
Only Aggregates should produce events.
They reflect a consistency boundary (the Grain that is the Aggregate (Entity)
This message was deleted
you have event handlers, there can be 0..N event handlers per Event type raised by the Producer (Aggregate)
That is where the work to "do stuff" after the event is triggered.
You have all of this basically in Ray now.
I think Ray is very close...
Elan Hasson
@ElanHasson
just needs some decoupling of a few things
The broker stuff in IConsumer is too complicated and could probably be simpler
nless
@luohuazhiyu
I think so too, so the project intends to separate pub and sub completely and run them in different services
Elan Hasson
@ElanHasson
What do you mean?
the only publishing should happen from Producers (Aggregates)
nless
@luohuazhiyu
Producers and consumers can run in different services
Elan Hasson
@ElanHasson
Consumers should always be in different services
nless
@luohuazhiyu
Now they're coupled
Elan Hasson
@ElanHasson
consumers should be on the Read side of CQRS
the Event Store/Snapshots/Publishing should be on the Write-Side.
nless
@luohuazhiyu
yes
Elan Hasson
@ElanHasson
read that book i sent
nless
@luohuazhiyu
Recently, I was looking at the design ideas of vert. X
Elan Hasson
@ElanHasson
It explains a widely accepted way to do this system
nless
@luohuazhiyu
It's a good book
Elan Hasson
@ElanHasson
oh, you've read it?
nless
@luohuazhiyu
I bought this book, but I haven't read it carefully
Elan Hasson
@ElanHasson
yeah, go read it, especially the chapers on Aggregates, Architecture (specifically Event-Sourcing), and Appendix A Aggregates and Event Sourcing: A+ES .
raolan
@raolan
请问大佬有QQ或者QQ群吗
交流的
Elan Hasson
@ElanHasson
@luohuazhiyu are you around?