Understanding Campaign Listener Clustering and Listener Failover – Part 2
Clustered Listener Environments With the introduction of Clustered listener setups in Campaign, you have to think of them as a setup with multiple independently operating listener nodes that are being directed requests from a centralized entity. Each listener process behaves as it would in a single listener environment (See Part 1 of this Blog for more information), independently starting up and shutting down unica_acsvr processes local to its machine and maintaining its own unica_aclsnr.udb file. Each listener node does NOT share information. They act like individual, independent SINGLE listener nodes even though a "master listener" is managing them. The following shows a depiction of what a Clustered Campaign Listener setup would look like. Think of a master listener process as a load balancer. When a request comes down from the Campaign J2EE Web application server to login to Campaign or to view/edit/run a flowchart, instead of the Campaign web application talking to a specific listener to do that, it passes those requests over to the master listener in a clustered setup. The master listener then reviews its configuration settings to know which child listener node should take on this task. Once the Master listener determines which child listener node should receive the request, the request is passed along to that child listener node. At that point, the child listener node on that specific machine processes the request as if it was a single listener node running in a non-clustered setup. It spawns applicable unica_acsvr processes, and those unica_acsvr processes perform the requested action. The listener node then updates its local copy of unica_aclsnr.udb to understand the unica_acsvr's it's managing. No other child listener in the cluster has any idea about what other child listeners are working on. All activity is localized to a single child listener node. The child listener...