Hi Tomek, On Mon, Jul 9, 2018 at 2:06 PM, Tomek Rękawek <[email protected]> wrote: > 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? >
Indeed the problem statement is exactly same for ActiveDeletedBlobCollectorMBeanImpl. I've 2 subsequent questions: * why was it still useful to expose multiple instances of RevisionGCMBean - should it not have been more useful/backward compatible [0] (or maybe it's already there but I'm unable to see where it is happening) to have single exposed implementation which multiplexes as it seems fit ** Basically, afaict, repository level/checkpoint operations are implicitly singleton per repository - that the composite node store is multiplexing across multiple underlying store should not, imo, affect what's being exposed. * I can't quite find where "role" is being set for DocumentNodeStore (I think I can see where seg store is doing it). Also, does it mean that any new store needs to be aware that it needs to expose role? [0]: https://issues.apache.org/jira/browse/OAK-5309?focusedCommentId=16020939&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16020939 Thanks, Vikas
