Monitoring File Event Listeners

In the Central Log, a new STENG File Event Listener Engine entry is available in the Module column:

To describe how the File Event Listener logs are managed and how to read them, let’s suppose you have the File Event Listener Engine installed on 2 different peers, Peer1 and Peer7:

• On Peer1, the File Event Listener is the leader and monitors directories.

• On Peer7, the File Event Listener is correctly configured and keeps waiting as long as needed. This happens because only one Peer leader can exist and in our case the leader is Peer1.

The Message column of the Central Log lists the phases the File Event Listener Engine goes through. The last entry shows that it is running as leader on Peer1:

On Peer7 as well the File Event Listener Engine has several entries listing the phases. Since it is not running as leader, no entry about having the leader lock will appear:

If Peer1 is shut down, the File Event Listener Engine configured on Peer7 becomes the leader and starts monitoring the directories. The Central Log for Peer1 will show: FEL engine terminated

And for Peer7: FEL Engine running with leader lock acquired

From now on, the File Event Listener Engine installed on Peer7 is the leader. Note that it will remain leader until it is shut down. Therefore, the roles of the File Event Listener Engines on Peer1 and Peer7 are now reversed:

• File Event Listener on Peer7 is the leader and monitors directories.

• File Event Listener on Peer1 is active and will keep waiting as long as needed.

When Peer1 is up and running again, the last entry in the Central Log will be: FEL Engine started

Each File Event Listener controls two actions that can occur in the directories it monitors:

• new files added to the directories

• existing files updated in the directories

When one of these actions occurs, an existing on-demand FEL input contract is triggered to perform actions. To give an example, the File Event Listener Engine configured on Peer7 can be associated to an input Contract called ContractNameNew that moves files to a virtual directory in Data One. Let’s see what we can find in the Central Log:

• the on-demand FEL input Contract associated to Peer7 is in the Contract column.

• the name of the on-demand FEL input contract triggered (ContractNameNew), the action executed (ActionNameNew), the Peer (Peer7), the workerId and other information is listed in the Message column.

In the Central Log the entries of a File Event Listener can be filtered by name. To do so, enter the name of the File Event Listener in the JOB column. Additionally, you can select STENG File Event Listener Engine in the MODULE column. Doing so, all Logs for the File Event Listener specified will be listed.

Note that when selecting the STENG File Event Listener Engine option in the Module column, the Job column will list File Event Listeners. Since a JobID is not available in this phase, the Job column is used to identify anything happening in the STENG related to a specific worker.

Logs can also be grouped by correlation ID, clicking the GROUP BY LCID (CORRELATION ID) button. In this way, logs belonging to the same instance are displayed together and issues can be checked more easily.

The File Event Listener sets multiple identities in the Central Log:

• A long-running identity that groups together all the activities of a given File Event Listener for each STENG cluster peer, using the LCID column.

• A short-running identity applied to each contract invocation (i.e., to each event of each monitored file), using the DFIID column.