Hi Abimaran, On Fri, Aug 18, 2017 at 2:44 PM, Abimaran Kugathasan <[email protected]> wrote:
> Hi Asanka, > > We are embedding MB components into APIM and for minimum HA in API > Manager, there will be two active nodes. So will MB components/features > decide which node should be active and passive based on start up order > initially? > Yes, the MB component will decide on the active node. > > Also, are you expecting a client to send messages to both nodes (multi > cast) and passive MB nodes will reject them? Because in API Manager > perspective both node as active, so there could be a chance to configure a > gateway with active MB node as failover node. > No, the clients don't have to publish messages to both node. You can configure the broker URL with failover options. If the client connects to the passive node first it will get rejected and try to connect to the second node in the broker list. After connecting to the active node clients can resume publishing messages. Therefore it will not be an issue even if you connect to the pssive node first. WDYT? > On Thu, Aug 17, 2017 at 4:45 PM, Asanka Abeyweera <[email protected]> > wrote: > >> Hi all, >> >> I am working on implementing active-passive clustering on top of the new >> MB4 architecture. Current message delivery implementation in MB4 is not >> capable to work in a multi-node environment. If we run more than one node >> concurrently, messages can be duplicated since all nodes start delivering >> messages available for a queue in the message store. We have to make the >> MB4 nodes cluster aware to rectify this behavior. >> High-level design >> >> We are planning to use the available RDBMS leader election mechanism to >> decide on the active node. All the non-leader nodes will be passive nodes >> and will reject all incoming requests. The clients should be configured >> with failover URLs so that they can failover to the active node from >> passive nodes. >> >> Tasks to do when the active node becomes passive >> >> 1. >> >> Enable rejecting all requests to broker node except the CLOSE-OK >> 2. >> >> Close existing AMQ connections (both publishing and consuming) >> >> >> Tasks to do when the passive node becomes active >> >> 1. >> >> Start accepting all requests to broker node >> >> >> The assumption here is the active components like the Inbound disruptor, >> outbound disruptor, delivery task managers will stop working (consuming >> resources) when the incoming requests are stopped and subscriptions are >> removed in passive nodes. >> >> >> >> - >> >> Filtering message events will be handled by “InboundEventGatekeeper”. >> - >> >> DeliveryHandler will also be modified to stop delivering messages >> when a node becomes passive. >> - >> >> All the connections will be closed using the server connection >> registry >> >> >> Suggestions and feedback are appreciated. >> >> -- >> Asanka Abeyweera >> Senior Software Engineer >> WSO2 Inc. >> >> Phone: +94 712228648 <+94%2071%20222%208648> >> Blog: a5anka.github.io >> >> <https://wso2.com/signature> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks > Abimaran Kugathasan > Senior Software Engineer - API Technologies > > Email : [email protected] > Mobile : +94 773922820 <+94%2077%20392%202820> > > <http://stackoverflow.com/users/515034> > <http://lk.linkedin.com/in/abimaran> > <http://www.lkabimaran.blogspot.com/> <https://github.com/abimarank> > <https://twitter.com/abimaran> > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Asanka Abeyweera Senior Software Engineer WSO2 Inc. Phone: +94 712228648 Blog: a5anka.github.io <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
