Troubleshooting

Owned by Andy Brook [Plugin People] (Unlicensed)
Last updated: May 06, 2010Version comment
4 min read

Common Problems

The configuration of JEMH is getting a little complex, there are gotchas that are sometimes tricky to spot, this page will document the ones that come up often.

Rejected email should always result in a hint-O-gram email telling you (perhaps tersely) why it couldn't be processed.
Unless otherwise stated, all 'values' are case insensitively matched
Regexp fields will match exactly, unless wildcards are used

JEMH doesn't create issues

Installation related

  1. You could have found a bug, please check the logs, if you see reference to "Bug" from com.javahollic.jira packages, create an issue in the Jira Project, attaching compressed actual log files (screenhots don't help)

  2. You believe JEMH to be a plugin and to just work, it doesn't (currently) even appear as a plugin, you need to set it up (see JEMH Installation for Jira 3.9.2 - Jira 3.13.x / JEMH Installation for Jira 4.x).

  3. You tried to add JEMH as a service, it wont work, you need to create a POP/IMAP service, and associate JEMH with it (see JEMH Installation for Jira 3.9.2 - Jira 3.13.x / JEMH Installation for Jira 4.x)

  4. The Configuration file was not specified in the Jira Handler settings (its mandatory)

  5. The Configuration file could not be loaded by JEMH (verify filename matches and that it exists in WEB-INF/classes)

  6. There is no mail in the POP/IMAP mailbox (verify with a mail client)

  7. The password in the Jira POP Server settings is wrong (check Jira logs, verify correct password with a mail client)

  8. You have upgraded from Jira 3.13.x and forgotten to update the emailFieldProcessorPackageList Configuration option.

  9. The Configuration file includes a catchEmail option that does not case insensitively match the to: addresses of emails (verify with a mail client)

  10. The from: email address is not associated with a real Jira user and no defaultReporterUsername is provided

  11. A defaultReporterUsername was provided, and defaultReporterOverridesDerivedReporter=true, however, the defaultReporterUsername does not have authority to create issues in the target project

  12. A defaultProject was specified but the project is incorrectly identified, if no project was identified through other means, the email would be rejected

  13. projectAutoassign is set true, meaning the KEY@someplace.com will be checked for as a valid project key. If no defaultProject was specified, and the KEY doesnt match a project KEY, it will be rejected.

  14. projectDefault.ABC.domain=.*@somedomain.com, was specified, but no defaultProject was, only issues from this(or similar config entries) will result in issue creation (unless they actually specify the project)

  15. jemhAddresseeRegexps is specified and contains a value which is incompatible with the actual to: address of the inbound mail. If the catchEmail was also specified, a classic gotcha is to make have this value incompatible, result in a 100% reject.

Don't seem to be getting a new feature doc'd as being in the latest revision.

  1. You have added an updated JAR to the WEB-INF/lib folder but forgotten to remove the old one, which could be found first by the classloader.

Field Processor specific

Nagios

Duplicate issues do not comment on their original, generating new issues instead

  1. No Nagios configuration could be found, or its not valid, under which circumstance Nagios would not 'claim' the mail, and it would be processed by another handler. This can be proven by enabling the indicateWhichProcessorProcessedMail=true option.

  2. The Nagios Field Processor does exact string matching with the key phrase tested against the entire set. Consequently, the subject MUST be identical bar that phrase in order to be found and associated.

  3. Assuming you have phraseSet entries (starting at index of 1), the value is CSV, any whitespace between the commas is retained, so "OK " will not match "OK-".

  4. If you have selected phraseSet values that are duplicated, you will get mis-association.

  5. If Nagios FP configuration is present, at least one phraseSet must be defined.

  6. Issues going to defaultProject not nominated fp.nagios.project, perhaps the given project key is not valid

  7. The fp.nagios.fromEmailAddressRegexps=nagios@.* configuration is a further restriction on mails that got through the catchEmail filter (if it was specified). Inbound from: mail must match the given regexp. If not, the mail will not be handled by the Nagios Field Processor (verify by setting the indicateWhichProcessorProcessedMail=true option, and checking the created issue)

  8. A Nagios specific 'reporter' has been defined through fp.nagios.reporter=xxxxx however, that user does not have privilege to create issues, and if defined, and if privileged, other defaults for reporter may apply.

  9. Issues not commenting could be due to a value specified for fp.nagios.unresolvedIssueMatchTimeLimit (eg =1d), but the issues already created were created outside that duration.

Issues aren't getting closed automatically, or are closed unexpectedly

  1. You specified fp.nagios.resolvedWorkflowAction=resolve, resolve is a first word match on "Resolve Issue", it needs to match whatever workflow String you want (which of course, needs to be valid for the state of the issue). If you did not enable the useFirstWordOnlyWorkflowNameMatch=true option, the worklfow step would not be found, and closure would not happen. But, in such circumstances, you would probably get a hint-O-gram to the fp.nagios.overrideHintOgramEmailAddress.

  2. The fp.nagios.resolvedWorkflowResolution needs to specify a valid resolution, eg 'fixed'

  3. The order of values in phraseSets is important, the first entry is deemed the automatic 'closure' event phrase.