Hi Leader/follower - I know this from Zookeeper world, but "follower" is far from being "passive" - it actively receives synchronization events/objects/notifications and tries hard not to stay behind. Definitely not related to a Karaf container waiting for a lock (unless the discussion already moved to something different ;)
regards Grzegorz Grzybek wt., 28 lip 2020 o 18:33 Jean-Baptiste Onofre <j...@nanthrax.net> napisał(a): > Hi, > > Yeah, leader/follower (similar to Kafka wording) sounds good. > > Regards > JB > > > Le 28 juil. 2020 à 18:09, Matt Pavlovich <mattr...@gmail.com> a écrit : > > > > Hey JB- > > > > Interesting point. I’ve generally used the locking to keep bundles from > going active as a way of having the service not know anything about karaf. > I suppose listening for the lock event could be used at the app level. > > > > +1 Christian’s suggestion for ‘leader’ / ‘follower’. > > > > -Matt > > > >> On Jul 28, 2020, at 2:55 AM, Jean-Baptiste Onofre <j...@nanthrax.net> > wrote: > >> > >> Hi, > >> > >> I mean Runtime, and depending of the lock level you can have all > bundles active on both instances. > >> > >> Standby could be fine if it’s documented, but IMHO, it’s not really a > standby (like ActiveMQ one for instance). > >> > >> Regards > >> JB > >> > >>> Le 27 juil. 2020 à 20:46, Matt Pavlovich <mattr...@gmail.com> a écrit > : > >>> > >>> JB- > >>> > >>> Are you referring to ‘Karaf Cave’ or ‘Karaf Runtime’? > >>> > >>> I think with Karaf Runtime locking, the warm boot tends to be to not > have all bundles active, for things that need to be singletons, such as > scheduled jobs and pollers. The Karaf Runtime is running enough to be > monitored, but generally not running any active workload. This is what I > was referring to as ’standby’. > >>> > >>> I think ‘primary’ and ‘replica’ work great for replication use cases. > >>> > >>> -Matt > >>> > >>>> On Jul 27, 2020, at 12:51 PM, Jean-Baptiste Onofre <j...@nanthrax.net> > wrote: > >>>> > >>>> No, I don’t think it’s accurate to Karaf. > >>>> > >>>> Standby means that the instance is not "active", but actually, in the > case of Karaf, it’s active and replicate the "master/active". > >>>> > >>>> That’s why I proposed primary/secondary. We can also use > active/replica if you think it’s more accurate. > >>>> > >>>> Regards > >>>> JB > >>>> > >>>>> Le 27 juil. 2020 à 18:26, Matt Pavlovich <mattr...@gmail.com> a > écrit : > >>>>> > >>>>> My $0.02, the ‘primary’ ’secondary’ numeric-style terms can be > misleading, since you can have multiple ’slave’ nodes and lock recovery is > non-deterministic. So the ’secondary’ node doesn’t mean it is ’second’ in > line to take over. > >>>>> > >>>>> Thoughts on aligning with the proposed terms same as ActiveMQ? > >>>>> > >>>>> master -> ‘active’ > >>>>> slave -> ’standby' > >>>>> > >>>>> -Matt Pavlovich > >>>>> > >>>>>> On Jul 27, 2020, at 1:21 AM, Jean-Baptiste Onofre <j...@nanthrax.net> > wrote: > >>>>>> > >>>>>> Hi guys, > >>>>>> > >>>>>> I would like to propose new wording in some Karaf designs: > >>>>>> > >>>>>> - In Karaf runtime, I would like to rename master/slave to > primary/secondary > >>>>>> - in Cellar, I would like to rename blacklist/whitelist to > allowlist and deny list > >>>>>> > >>>>>> Thoughts ? > >>>>>> > >>>>>> Regards > >>>>>> JB > >>>>> > >>>> > >>> > >> > > > >
