profile image
Deborah Matyi
Unica Senior Technical Support Engineer
Deborah is presently a Level 2 Senior Technical Support Engineer for Unica products and has been for over 10 years, starting her Unica career at Unica Corporation in 2010. She acts as the owner of client issues from submission to resolution. She has worked with Unica clients to ensure smooth installations/upgrades, provides an analysis of problems with workarounds and solutions, and has even assisted in troubleshooting environmental issues related to web application servers, networks, databases, and more. She has a strong knowledge of all products in the Unica suite/family as well as integrations of those products with other 3rd party tools and applications such as those from Acoustic and IBM.
Posts by Deborah Matyi
Marketing & Commerce | April 29, 2020
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...
Marketing & Commerce | April 21, 2020
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 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...
a/icon/common/search Created with Sketch.