Configure Email Options

Configure Email Options

Global default values for specific email related settings, here shown from v1.0.15, with the new Flush Type feature, allowing the queue to be flushed at a nominated time (or times), daily.

Max Events per email  - How many events an email should contain, an event is one action, e.g. one ISSUE_CREATE and ISSUE_COMMENTED equal 2 events.

Emails per Flush per Recipient - How many emails should a recipient get per flush.  This metric comes into play when either (a) the Max Events per Email is low enough to not satisfy the generation of events, or (b) attachments are enabled and have exceeded total limits for the email.  Where emails are not flushed 'this time' subject to all events fitting into the flush window 'next time' they will be sent later.  Reducing the overall duration between notifications will reduce the likelihood of this scenario.

Flush Type:

  1. Periodicity
    1. Periodicity of Flush: Hours / Minutes – This is the amount of time between automated flushing of the queues.  The time is between the start of the one queue flush and the start of the next.  For example if you have a periodicity of 1 hour and the queues are flushed at 1pm and takes five minutes then the next queue flush is at 2pm.  The periodicity has a minimum of five minutes and a maximum of 24 hours
  2. Time
    1. Time to Flush: HHMM,HHMM,HHMM,...  – Nominate in hours and minutes in 24hr style, one or more comma separated values, to nominate time at which flushes should occur.  Actual times may be up to 5minutes after nominated times to minimise loading.

Mail to Email Address - When emails are sent to non-JIRA users any "Add Comment" links in the email will open a new mail message so that a comment can be emailed to JIRA and subsequently added to the related Issue. The address that this Email is sent to is specified in this field.

Queuing Configuration

When the Mail Queues are flushed the underlying process does several things.  The first is to create a job (the Email Creator) that goes through all events that need sending, accumulating them for the user into an Email.  That Email is then added to a queue ready to send.  For each queue there is a Queue Processor that monitor the queued items and send these to the appropriate mail server.  If there are 3 queues with Email that need to be sent then there will be three Queue Processors and one Email Creator to fill those queues. 

The Queuing Configuration section defines the options used by the process added Email to the queues and to the Queue Processors.  The numbers in the square brackets  [ ] refer to the fields defined further down.

WARNING: Be careful when changing these options as this could have a very large impact on the computer being used and the processes it is trying to perform (i.e. running JIRA for the front end users)

Email Sending Steps:

Queuing Email Steps:


Sleep time when waiting for Email [1] - The amount of time (in milliseconds) that the Queue Processor sleeps for when there are no email waiting to be sent.  After this period of time the Queue Processor will check again for any emails to send and re-sleep if there are none. This sleep time allows the computer to perform other tasks.

Sleep time between Emails [2] - This is the amount of time (in milliseconds) that the Queue Processor sleeps for between processing an Email and checking if there are more Emails to process. This time allows the computer to perform other tasks.

No. of Queue Items before Blocking [3] - Each Queue will only allow a certain number of items to be placed on the Queue before the Email Creator will stop and wait.  The process of stopping and waiting is called blocking or being blocked. This option specifies the number of items on the queue before blocking. 

Sleep time between Blocking checks [4] - When the Email Creator is being blocked it sleeps a while before it checks to see if it is still blocked.  This options defines the sleep time (in milliseconds).  As with the previous sleep times this time gives the computer time to perform other tasks.

Max seconds to wait when Blocked [5] - The is a fail safe option designed to abandon being blocked if the wait is too long (in seconds).  If the wait is abandoned then the email will not be queue, or sent.  Instead the email will be left to a future queue flush.

Digest Exclusions

This section is repeated at the Mail Queue and User Profile screen.  If the JQL any of these screen matches then the event information will be sent immediately.  If any of them have "Also Digest Immediate Sends" then the event will also be digested.

Exclusion JQL - This options allows you to specify a JQL statement that will be used to determine in the notification of an event should be sent immediately, rather than digesting.

Also Digest Immediate Sends - If this option is checked then any emails sent immediately will also be digested.  The item in the digested email will be marked as "Already Sent".