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 "clusters" and each= one will use it'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 <<a href=3D"mailto:[email protected]">[email protected]</a>> = 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> > Osiris is quite a different type of thing to the other ones in your <b= r> > list in that it will always first write terms to disk and only then <b= r> > 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 fro= m <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 th= e <br> > production side and a "replica" member on the other side).<b= r> ><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=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--