Bryan, I'm not sure building something similar to the ProcessorInitializationContext is possible without changes to the framework itself. The framework is responsible for instantiating the initialization context - in both processor and authorizer. However, the AuthorizationInitializationContext is outside the context of the flow - where cluster/nodes have meaning. On the other hand, the ProcessorInitializationContext is instantiated from the FlowController where the cluster/nodes do have meaning.
-Mark On Tue, Aug 29, 2017 at 9:24 AM, Bryan Bende <bbe...@gmail.com> wrote: > Mark, > > I don't believe there is currently anything like this in Authorizer API. > > You would likely have to build something similar to what processors have... > > In ProcessorInitializationContext they get access to a NodeType which > tells them if they are currently primary or not. > > Then they can annotate a method with @PrimaryNodeStateChange to get > notified when primary node changes. > > -Bryan > > > > On Tue, Aug 29, 2017 at 8:08 AM, Mark Bean <mark.o.b...@gmail.com> wrote: > > Is there a way to get access to Cluster configuration state? > Specifically, > > can a Node determine which Node - or simply "itself" - is the Cluster > > Coordinator or the Primary Node? > > > > Use case: I have a custom authorizer which includes a background thread > to > > re-authorize users and policies in case a user's credentials have > changed. > > This thread can potentially change authorizations.xml and users.xml files > > which are kept in sync with ZooKeeper. I do not want each Node to execute > > the process making the same changes. It would be desirable to execute > this > > process on only one Node (Coordinator or Primary) and let ZooKeeper > > coordinate the changes across the Cluster. > > > > Thanks, > > Mark >
