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...

Single Listener Environments To understand how Campaign Listener clustering and its use in failover work, you should first understand how the Campaign listener works in general. The following diagram depicts the basic setup of a single listener environment. In a single Campaign listener setup, the listener receives requests from the Campaign J2EE deployment in the web application server for specific Campaign feature actions made in the Unica UI. For example, after a user logs into the Unica UI and clicks on a Campaign-related feature (such as the Campaign > Campaigns menu item), a request is sent to the Campaign listener. It will fork off a separate independent process called “unica_acsvr” that runs on the Campaign analytic server (the machine where the listener process is running). This unica_acsvr process becomes the user’s Campaign Login session. Each user has their own unica_acsvr process for their login session. If the user then clicks on a Flowchart tab within a Campaign, the listener receives another request from the Campaign J2EE deployment to fork another separate unica_acsvr process that is exclusive to that flowchart. This unica_acsvr process loads into its memory the flowchart.ses file contents and any cell run results from prior executions of that flowchart if any (so green checkmarks and output cell counts can be displayed on each process box). Each flowchart accessed by users has its own unica_acsvr process started. Even when automated flowchart tasks (such as those started by the Unica scheduler or the Campaign utility unica_svradm) are started to execute flowchart logic, a single unica_acsvr process for that flowchart is spawned by the listener. Anytime a unica_acsvr process is spawned by the listener, the listener also adds a reference for that unica_acsvr into the Campaign_home/conf/unica_aclsnr.udb file. This file is the means of the listener understanding which unica_acsvr processes are running...