Persistence/acks question

[philippsushkin]

I am trying to figure out how to implement following:

1). infinite persistable retransmission buffer

multicast publisher without any limitation by receivers
receivers "late join" handled somehow (with unicast retransmits like on naks or smthing custom)
persistent means that i can stop/start publisher application and continue publish where I was finished.
I agree to pay some price for that, in general I see custom buffer/term management where they not rotated but asynchronously written to disk.
Are there some extension points I can play with?

2). handle/manage receiver cumulative acks after message processing by app on subscriber side in consistent but more or less cheap way on publisher

use receiver status message?
separate channel for acks?

Could you please advice if it is achievable/reasonable/applicable to Aeron at all.
Or just point me direction/extension points where to dig.

Thanks in advance.

[mjpt777]

All of these points are being considered. We plan to add the necessary APIs to Aeron so that services such as replication, persistence, and historical query/replay can built on top without impacting the performance of the core.

Because of the core design decisions to have all the log buffer data structure as effectively immutable within a constrained range, plus the ability to uniquely identify an exact position in a stream across time these things can fall out relatively easily. @tmontgomery and I had this direction in mind right form the outset.

Watch this space as more will come in the not too distant future.