Hi, I think we should discuss this. The right now, we use some of the beans like "global static" singletons. This might be a mistake, but it's like that. Now by introducing a second bean, this "contract" breaks. It's kind of like breaking backward compatibility...
Regards, Thomas On 09.07.18, 10:36, "Tomek Rękawek" <[email protected]> wrote: Hello Vikas, I think there was a similar case, described in OAK-5309 (multiple instances of the RevisionGCMBean). We introduced an extra property there - “role” - which can be used to differentiate the mbeans. It’s similar to the option 2 in your email. The empty role means that the mbean is related to the “main” node store, while non-empty one is only used for the partial node stores, gathered together by CNS. Maybe we can use similar approach here? Regards, Tomek -- Tomek Rękawek | ASF committer | www.apache.org [email protected] > On 5 Jul 2018, at 23:59, Vikas Saurabh <[email protected]> wrote: > > Hi, > > We recently discovered OAK-7610 [0] where > ActiveDeletedBlobCollectorMBeanImpl got confused due to multiple > implementations of CheckpointMBean being exposed in composite node > store setups (since OAK-6315 [1] which implemented checkpoint bean for > composite node store) > > While, for the time being, we are going to avoid that confusion by > changing ActiveDeletedBlobCollectorMBeanImpl to keep on returning > oldest checkpoint timestamp if all CheckpointMBean implementations > report the same oldest checkpoint timestamp. But that "work-around" > works currently because composite node store uses global node store to > list checkpoint to get oldest timestamp... but the approach is > incorrect in general as there's no such guarantee. > > So, here's the question for the discussion: how should the situation > be handled correctly. Afaict, there are a few options (in decreasing > order of my preference): > 1. there's only a single checkpoint mbean exposed (that implies that > mounted node store services need to "know" that they are mounted > stores and hence shouldn't expose their own bean) > 2. composite node store's checkpointMBean implementation can expose > some metadata (say implement a marker interface) - discovering such > implementation can mean "use this implementation for repository level > functionality" > 3. keep the work-around to be implemented in OAK-7610 [0] but document > (ensure??) that the assumption that "all implementations would have > same oldest checkpoint timestamp" > > Would love to get some feedback. > > [0]: https://issues.apache.org/jira/browse/OAK-7610 > [1]: https://issues.apache.org/jira/browse/OAK-7315 > > > Thanks, > Vikas
