In our particular case, we have the problem that sometimes Crowd goes down (planned or otherwise, doesn't matter why or how) and when this happens, JIRA stops creating tickets from incoming mail, instead forwarding all incoming mail to admins along with a stacktrace that starts like this:

com.atlassian.util.concurrent.LazyReference$InitializationException: org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: Could not execute JDBC batch update; nested exception is org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update

That's our case, but it happens with other errors as well: whenever an incoming mail can't be turned into a JIRA ticket, the mail just gets forwarded to the admin along with the error stacktrace, and then JIRA just removes the mail from its queue.

I think it'd be better if JIRA sent a warning about all this to the admin (instead of an error), so that the admin can check it out if it's actually something unexpected and/or persistent, but have JIRA also keep incoming mail in its queue to try again later - or maybe at least when the cause is Crowd or whatever other external service being down.

The admin may be able to fix the problem, but usually can't do much with the e-mails except recreating them all by hand in JIRA (or forwarding them back to JIRA, but then the reporter on those tickets comes up wrong...).

So, to summarize: is it possible to have JIRA keep incoming mail that can't be turned into tickets in its queue if the problem is caused by external services being down (or just all the time)?