<div dir="ltr">You can have multiple osiris "clusters" and each one will use it's own connection</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Apr 2022 at 12:10, Dave Cottlehuber <<a href="mailto:dch@skunkwerks.at">dch@skunkwerks.at</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 1 Apr 2022, at 10:48, Karl Nilsson wrote:<br>
> Osiris is quite a different type of thing to the other ones in your <br>
> list in that it will always first write terms to disk and only then <br>
> replicate them (over TCP). That said it could do a decent replication <br>
> job if you want a local buffer to decouple the production of terms from <br>
> the replication part. Osiris does still need a dist erl connection for <br>
> coordination messages and you'd have to modify the quorum commit <br>
> semantics to fit your use case (e.g. a "leader" member on the <br>
> production side and a "replica" member on the other side).<br>
><br>
> Cheers<br>
> Karl<br>
<br>
Thanks Karl,<br>
<br>
Osiris is definitely worth considering - there is always the risk of<br>
connection loss, and need to restart from a known checkpoint, the buffer<br>
could come in handy. Would it be able to make use of multiple TCP<br>
connections?<br>
<br>
A+<br>
Dave<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><b>Karl Nilsson</b></div></div></div>