Re: options for high-throughput connections between nodes

Karl Nilsson <[email protected]> Fri, 1 Apr 2022 12:21:19 +0100
Newsgroups gmane.comp.lang.erlang.general
Message-ID <CAHC35TDQSoAAgSm7_Bzrt-A855rO+LW2TSRgYiftMBKfdtsjNw@mail.gmail.com>
--000000000000f0bc8c05db95fa9d
Content-Type: text/plain; charset="UTF-8"

You can have multiple osiris "clusters" and each one will use it's own
connection

On Fri, 1 Apr 2022 at 12:10, Dave Cottlehuber <[email protected]> wrote:

> On Fri, 1 Apr 2022, at 10:48, Karl Nilsson wrote:
> > Osiris is quite a different type of thing to the other ones in your
> > list in that it will always first write terms to disk and only then
> > replicate them (over TCP). That said it could do a decent replication
> > job if you want a local buffer to decouple the production of terms from
> > the replication part. Osiris does still need a dist erl connection for
> > coordination messages and you'd have to modify the quorum commit
> > semantics to fit your use case (e.g. a "leader" member on the
> > production side and a "replica" member on the other side).
> >
> > Cheers
> > Karl
>
> Thanks Karl,
>
> Osiris is definitely worth considering - there is always the risk of
> connection loss, and need to restart from a known checkpoint, the buffer
> could come in handy. Would it be able to make use of multiple TCP
> connections?
>
> A+
> Dave
>


-- 
*Karl Nilsson*

--000000000000f0bc8c05db95fa9d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You can have multiple osiris &quot;clusters&quot; and each=
 one will use it&#39;s own connection</div><br><div class=3D"gmail_quote"><=
div dir=3D"ltr" class=3D"gmail_attr">On Fri, 1 Apr 2022 at 12:10, Dave Cott=
lehuber &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; =
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 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>
&gt; Osiris is quite a different type of thing to the other ones in your <b=
r>
&gt; list in that it will always first write terms to disk and only then <b=
r>
&gt; replicate them (over TCP). That said it could do a decent replication =
<br>
&gt; job if you want a local buffer to decouple the production of terms fro=
m <br>
&gt; the replication part. Osiris does still need a dist erl connection for=
 <br>
&gt; coordination messages and you&#39;d have to modify the quorum commit <=
br>
&gt; semantics to fit your use case (e.g. a &quot;leader&quot; member on th=
e <br>
&gt; production side and a &quot;replica&quot; member on the other side).<b=
r>
&gt;<br>
&gt; Cheers<br>
&gt; 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=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div><b>Karl Nilsson</b></div><=
/div></div>

--000000000000f0bc8c05db95fa9d--