0

My use case is this - Several events are produced and dispatched onto a threadpool. Each event is processed separately and the output of the processing isn't needed for some reconciliation later. (So, one thread need not wait for others) Each thread does the same task but with different events. Each thread relies on some statically maintained data in a local cache. (say a concurrent hashmap).

Since the hashmaps in cache will have to lock/unlock anyway, is the lmax disruptor with the ring buffer a good choice of architecture?

  • You do not have a consumer? – Erik Sep 06 '18 at 11:04
  • An implementation would be to have several consumers with filters so that each event is processed by one single consumer. (Thereby not making use of multicast). I'm asking whether this implementation (or any other disruptor implementation) is any good? – degenaristotle Sep 06 '18 at 11:09
  • the disruptor is very good but it depends on the use case. That's why I asked wether you have a consumer. – Erik Sep 07 '18 at 09:48

0 Answers0