Understanding Campaign Listener Clustering and Listener Failover - Part 1

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 and which unica_acsvr processes to manage and communicate with. Unica_acsvr processes for flowcharts starts and remains “up” whenever a user is viewing or editing a flowchart or even when a flowchart is executing its logic.

If a user exits Edit mode or navigates from viewing a flowchart in the UI or when a flowchart run has completed its execution- a signal is sent to the listener to pass onto the respective unica_acsvr to have it shut down. Each time a unica_acsvr process starts, an entry is added to this unica_aclsnr.udb file by the Campaign listener, and each time a unica_acsvr process ends, an entry is removed from the unica_aclsnr.udb file by the Campaign listener, making this a dynamically changing file.

Overall the unica_acsvr processes require the listener to be available at all times to send/receive information to/from the J2EE side of Campaign. It enables the Unica UI to reflect the view, edit, or run results of the unica_acsvr process related to that flowchart. If the listener is down or unresponsive, the flowchart and user login sessions would also become unresponsive. It happens as the listener (or “middle man”) is no longer available to communicate to/from the Campaign J2EE deployment and, ultimately, the user workstations. The UI would become frozen, and the unica_acsvr processes would stop functioning properly. The only way to fix this is to have users close their browser, to disconnect from their Campaign login sessions, and the listener problem would need to be fixed. Users can then open a new browser, login again, and resume operations.

Therefore, in a single listener environment, should the listener become unavailable or unresponsive, it means downtime for the system until the listener is operational again. Learn more about Campaign Listeners in the second part of the blog- Understanding Campaign Listener Clustering and Listener Failover – Part 2 

To read more about the Clustered Listener setups, subscribe to the Unica blog and Stay Updated.