You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Степан Гащишин <st...@gmail.com> on 2018/11/16 20:49:08 UTC
Segment Tar based Sling clustering
Hello,
I am curious about the available ways to cluster sling, and from current
standpoint I can observe next 3 options:
- obviously Mongo based deployment
- Segment Tar based deployment ( where two instances of Sling will use the
same, mounted repository folder)
- remote Oak deployment ( where two Slings will access standalone Oak
server, which will use Tar based repo inside)
My concerns are about latest 2 options. In theory i suppose third option
may be possible to work. And i majorly doubt regarding the second.
So that I want to ask community to describe if such ways of clustering are
possible, and maybe there are some extra which i missed.
Thank you in advance,
Stepan
Re: Segment Tar based Sling clustering
Posted by Степан Гащишин <st...@gmail.com>.
Hi,
Thank you all very much, we've got the same results, and now with the
confirmation from community we could for sure take a look at different
options.
Stepan
вт, 20 нояб. 2018 г. в 01:57, Robert Munteanu <ro...@apache.org>:
> Ah, yes, that does makes sense.
>
> Thanks,
>
> Robert
>
> On Tue, 2018-11-20 at 09:31 +0000, Nicolas Peltier wrote:
> > No i haven't tried that and I would not bet on it.
> > I was referring to 2+ separate segment tar based instance that are
> > written on with "broadcast" means like distribution.
> >
> > On 20/11/2018 10:11, "Robert Munteanu" <ro...@apache.org> wrote:
> >
> > Hi,
> >
> > On Mon, 2018-11-19 at 16:11 +0000, Nicolas Peltier wrote:
> > > Note that option 2 is the easiest option in case you are
> > clustering
> > > for read only (high availability scenario)
> >
> > If by 2 you mean " Segment Tar based deployment ( where two
> > instances
> > of Sling will use the same, mounted repository folder)" that was
> > not
> > possible last time I tried.
> >
> > The SegmentStore does not work on a read-only file-system as it
> > eagerly
> > aquires the journal lock and starts writing (IIRC) and also can't
> > work
> > with multiple processes sharing the same filesystem location.
> >
> > Did you manage to get this working at some point?
> >
> > Thanks,
> >
> > Robert
> >
> >
> >
>
>
>
Re: Segment Tar based Sling clustering
Posted by Robert Munteanu <ro...@apache.org>.
Ah, yes, that does makes sense.
Thanks,
Robert
On Tue, 2018-11-20 at 09:31 +0000, Nicolas Peltier wrote:
> No i haven't tried that and I would not bet on it.
> I was referring to 2+ separate segment tar based instance that are
> written on with "broadcast" means like distribution.
>
> On 20/11/2018 10:11, "Robert Munteanu" <ro...@apache.org> wrote:
>
> Hi,
>
> On Mon, 2018-11-19 at 16:11 +0000, Nicolas Peltier wrote:
> > Note that option 2 is the easiest option in case you are
> clustering
> > for read only (high availability scenario)
>
> If by 2 you mean " Segment Tar based deployment ( where two
> instances
> of Sling will use the same, mounted repository folder)" that was
> not
> possible last time I tried.
>
> The SegmentStore does not work on a read-only file-system as it
> eagerly
> aquires the journal lock and starts writing (IIRC) and also can't
> work
> with multiple processes sharing the same filesystem location.
>
> Did you manage to get this working at some point?
>
> Thanks,
>
> Robert
>
>
>
Re: Segment Tar based Sling clustering
Posted by Nicolas Peltier <np...@adobe.com.INVALID>.
No i haven't tried that and I would not bet on it.
I was referring to 2+ separate segment tar based instance that are written on with "broadcast" means like distribution.
On 20/11/2018 10:11, "Robert Munteanu" <ro...@apache.org> wrote:
Hi,
On Mon, 2018-11-19 at 16:11 +0000, Nicolas Peltier wrote:
> Note that option 2 is the easiest option in case you are clustering
> for read only (high availability scenario)
If by 2 you mean " Segment Tar based deployment ( where two instances
of Sling will use the same, mounted repository folder)" that was not
possible last time I tried.
The SegmentStore does not work on a read-only file-system as it eagerly
aquires the journal lock and starts writing (IIRC) and also can't work
with multiple processes sharing the same filesystem location.
Did you manage to get this working at some point?
Thanks,
Robert
Re: Segment Tar based Sling clustering
Posted by Robert Munteanu <ro...@apache.org>.
Hi,
On Mon, 2018-11-19 at 16:11 +0000, Nicolas Peltier wrote:
> Note that option 2 is the easiest option in case you are clustering
> for read only (high availability scenario)
If by 2 you mean " Segment Tar based deployment ( where two instances
of Sling will use the same, mounted repository folder)" that was not
possible last time I tried.
The SegmentStore does not work on a read-only file-system as it eagerly
aquires the journal lock and starts writing (IIRC) and also can't work
with multiple processes sharing the same filesystem location.
Did you manage to get this working at some point?
Thanks,
Robert
Re: Segment Tar based Sling clustering
Posted by Nicolas Peltier <np...@adobe.com.INVALID>.
Note that option 2 is the easiest option in case you are clustering for read only (high availability scenario)
On 19/11/2018 12:27, "Julian Sedding" <js...@gmail.com> wrote:
Hi Stepan
This question is better suited for the Jackrabbit Oak list.
But here's my take anyways:
I am pretty sure that option 2 is not possible, because Segment Tar
assumes that the files are private to a single VM instance.
If I understand you correctly, in option 3 you are considering to use
some sort of remoting (e.g. RMI). While this may theoretically work, I
don't think you would get any (many?) of the benefits of a cluster.
Bottom line: Jackrabbit Oak offers different persistence options. Only
Mongo and RDBMS can be clustered. Segment Tar is implemented for a
different use-case (small, fast, independant instances).
Regards
Julian
On Fri, Nov 16, 2018 at 9:49 PM Степан Гащишин
<st...@gmail.com> wrote:
>
> Hello,
>
> I am curious about the available ways to cluster sling, and from current
> standpoint I can observe next 3 options:
> - obviously Mongo based deployment
> - Segment Tar based deployment ( where two instances of Sling will use the
> same, mounted repository folder)
> - remote Oak deployment ( where two Slings will access standalone Oak
> server, which will use Tar based repo inside)
>
> My concerns are about latest 2 options. In theory i suppose third option
> may be possible to work. And i majorly doubt regarding the second.
>
> So that I want to ask community to describe if such ways of clustering are
> possible, and maybe there are some extra which i missed.
>
> Thank you in advance,
> Stepan
Re: Segment Tar based Sling clustering
Posted by Julian Sedding <js...@gmail.com>.
Hi Stepan
This question is better suited for the Jackrabbit Oak list.
But here's my take anyways:
I am pretty sure that option 2 is not possible, because Segment Tar
assumes that the files are private to a single VM instance.
If I understand you correctly, in option 3 you are considering to use
some sort of remoting (e.g. RMI). While this may theoretically work, I
don't think you would get any (many?) of the benefits of a cluster.
Bottom line: Jackrabbit Oak offers different persistence options. Only
Mongo and RDBMS can be clustered. Segment Tar is implemented for a
different use-case (small, fast, independant instances).
Regards
Julian
On Fri, Nov 16, 2018 at 9:49 PM Степан Гащишин
<st...@gmail.com> wrote:
>
> Hello,
>
> I am curious about the available ways to cluster sling, and from current
> standpoint I can observe next 3 options:
> - obviously Mongo based deployment
> - Segment Tar based deployment ( where two instances of Sling will use the
> same, mounted repository folder)
> - remote Oak deployment ( where two Slings will access standalone Oak
> server, which will use Tar based repo inside)
>
> My concerns are about latest 2 options. In theory i suppose third option
> may be possible to work. And i majorly doubt regarding the second.
>
> So that I want to ask community to describe if such ways of clustering are
> possible, and maybe there are some extra which i missed.
>
> Thank you in advance,
> Stepan