How does JEMH work in a Data Center Environment

1 Introduction
2 How DC nodes are allocated

Introduction

This page details how JEMH functions within a Data Center environment and how nodes react to the various processes JEMH carries out.

How DC nodes are allocated

Interactive User (Creating/Commenting & Running Test Cases)

When a user logs into the clustered JIRA instance their HTTP request will be appointed to a node by the load balancer and a sticky session will be created.

Creating/Commenting:

Creating or commenting on issues through the JIRA UI will result in the node that the user has a sticky session set up with being used to create the issue, fire the ISSUE_CREATED event and for JEMH Event Listener to handle it.

Running Test Cases:

Test case execution is the same as above.

Inbound Mail Handling

JIRA schedules all message handlers for execution on any available DC node (standard or JEMH). Therefore JEMH could run on any DC node for the the ISSUE_CREATE/UPDATE process, subsequent event firing and handling by the JEMH Event Listener.

Handling of events with the JEMH Event Listener

For an arbitrary user who will have a sticky session with an arbitrary node, any issue actions generate event on that DC node to be handled by JEMH on that DC node. When processing events JEMH builds emails and adds them to the local node mail queue.

It is only possible to view mail that is enqueued when the user's sticky session points to the DC node with the message queued, i.e. the load balanced view will only show the mail that is on DC node that your sticky session is associated with.
In the event of a node failing, it would appear that mail queued on the DC node in question would be lost.

JEMH Background Jobs

JEMH uses JIRA Job Scheduling API such that the jobs execute on random DC nodes over time. Currently JEMH has two such jobs, one general Housekeeping job (for purging old audit history and adhoc attachments) and a Transport flush job (to reattempt failed non-SMTP Transport deliveries).