This page details how JEMH functions within a Data Center environment and how nodes react to the various processes JEMH carries out.
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.
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.
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.
|
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).