Agrona ring buffers

[Tullio Canepa]

Hi

I'm looking at Agrona to understand if and how it is possible to use its RingBuffers for implementing inter-thread messaging with multiple consumers... Any advice about this?

Thanks in advance,
Tullio

[Martin Thompson]

Do you mean multiple consumers where each message is removed by a consumer and the other consumers do not see them, or do you mean multiple consumers where each see all the messages? The later implementation is easier and can perform better. Or to put it another way do you require a queue or a multicast ring buffer?

[Tullio Canepa]

Good point, I've missed a key info... I mean a multicast ring buffer

[Martin Thompson]

Why not then use Aeron IPC? It's does better under contention from multiple producers than anything I've measured, has greater throughput than the ring buffer, plus it can have multiple consumers.

[Tullio Canepa]

OK it sounds great

What about the order in which multiple subscribers will see the published messages? Is the subscription registration order guaranteed during message delivery?

I'll take a look at Aeron code base but I think the response is in your L1 cache ;-)

Thanks again,
Tullio

--
You received this message because you are subscribed to a topic in the Google Groups "mechanical-sympathy" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mechanical-sympathy/Ymfq30Y1Uzg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Thompson]

There is no imposed order to the which the subscribers will see published messages. The subscribers are all polling the same direct publication with equal opportunity. The timeliness to which they see the changes is related to how often they poll.

[Tullio Canepa]

So if the multicast ring buffer is required to have predictable delivery order to multiple consumers, the solution comes back to Agrona implementing a sort of OneToManyRingBuffer and ManyToManyRingBuffer (it's just an idea to check if I understand... I would have to study a lot before even trying to approach the subject!) or do you see any other option?

Tullio

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Martin Thompson]

I'm not sure what you are asking for here. The messages are delivered to each subscriber in the other they were published. There is no ordering between subscribers, they all see all messages in the same order of publication. The messages are multicast to each of them.

[Tullio Canepa]

OK my fault, I've not explicitly stated my goal: for one project of mine I'm currently evaluating the usage of Aeron as communication transport between the Protocol Adapters and the Core Service, plus the usage of Disruptor as inter thread messaging library within the Core Service.

I'm trying to understand if I can use Agrona RingBuffers (or Aeron IPC, after your suggestion) instead of Disruptor RingBuffers with a similar semantics (in particular multiple consumers in chain) in order to reduce the number of library dependencies.

--

[Martin Thompson]

So if I'm understanding this correctly you have some gateways (protocol adapters) in your system that need to communicate with some central services. These central services take incoming events/messages and perform a pipeline of operations on them and then emit responses? This is the bit of information I think I've just gleaned, i.e. the pipeline processing. So you want something that can efficiently get the messages from the gateways to the central services and then process them in pipelines. 

You could use Aeron for the transmission of messages over the network to subscribers that then put the messages into IPC channels for local processing. Depending on the number of steps and complexity of your pipelines it might be more efficient to use the Disruptor for this vs a series of IPC channels. Without more details I could not judge which would be better.

The Disruptor is at its best managing a dependency graph of pipelines as often the same underlying ring buffer can be used. However it will take at least one copy to go from any messaging system to the Disruptor and then out again at the other end.

It would not be too difficult adding Subscriber dependencies to Aeron and is something I've considered. I've not had the need to do it so far. What would be required is for a Subscriber to track the position counter of another Subscriber(s) to gate progress. This would mean network communications and pipeline processing could all be done from the same set of log buffers.

[ymo]

In addition to Argona, if you find yourself going to the underlying ring buffer you might be able to achieve the same thing with jctools queues. However, when it comes to inter thread communications, both Agrona RingBuffers and jctools are missing the nice pipeline and DAG type graphs that come naturally with Disruptor. One thing that bothers me with Disruptor is that each node in the graph is supposed to be taken care by one single thread. In both agrona and jctools you are not limited by that. But again doing it is left as an exercise to the user. I have a scratch to add that to agrona or jctools one of these days unless someone else does it before me.

Regards

[Francesco Nigro]

AFAIK last time i've checked, the JCTools lacks a ringBuffer impl with variable sized slots, while Agrona had it for the Many2One version...!