Hi, It’s basically the case depending of the lock level. The user by configuration can have a complete "passive/standby" instance, or can have "active" instance syncing some bundle state.
That’s why I proposed primary/secondary as first attend as it covers both cases. Regards JB > Le 28 juil. 2020 à 19:37, Grzegorz Grzybek <gr.grzy...@gmail.com> a écrit : > > 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 >>>>>>> >>>>>> >>>>> >>>> >>> >> >>
