The Jira "Mail Error Queue" Health Check fails due to the error "service proxy has been destroyed"
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
As per Jira 9.8.0 release notes, this version introduced a new health check meant to monitor the Mail Error Queue. When this health check fails, a warning will show in the UI and also the warning below will be added to the Jira logs:
1
2024-09-10 16:50:10,767+0200 http-nio2-8080-exec-11 url: /rest/troubleshooting/1.0/check; user: jira-administrator WARN jira-administrator XXXXxXXXXXXXxX XXXXXX 127.0.0.1 /rest/troubleshooting/1.0/check [c.a.t.healthcheck.concurrent.SupportHealthCheckProcess] Health check 'Mail Error Queue' failed with severity 'warning': 'There are 10 emails in the error queue for this node.'This KB article will focus on 1 specific scenario that will make this health check fail.
Environment
Jira Data Center on any version from 9.8.0.
Diagnosis
Check the Jira Outgoing Mail log files, and look for the error "service proxy has been destroyed" as shown in the log snippet below:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 312024-08-14 14:18:01,351+0000 Sending mailitem com.atlassian.jira.mail.SubscriptionSingleRecepientMailQueueItem owner: 'someuser' ERROR anonymous Mail Queue Service [c.a.jira.mail.SubscriptionSingleRecepientMailQueueItem] service proxy has been destroyed org.eclipse.gemini.blueprint.service.importer.ServiceProxyDestroyedException: service proxy has been destroyed at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceDynamicInterceptor$ServiceLookUpCallback.doWithRetry(ServiceDynamicInterceptor.java:101) at org.eclipse.gemini.blueprint.service.importer.support.internal.support.RetryTemplate.execute(RetryTemplate.java:81) at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceDynamicInterceptor.lookupService(ServiceDynamicInterceptor.java:427) at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceDynamicInterceptor.getTarget(ServiceDynamicInterceptor.java:400) at org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceInvoker.invoke(ServiceInvoker.java:60) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:137) at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:124) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.eclipse.gemini.blueprint.service.util.internal.aop.ServiceTCCLInterceptor.invokeUnprivileged(ServiceTCCLInterceptor.java:70) at org.eclipse.gemini.blueprint.service.util.internal.aop.ServiceTCCLInterceptor.invoke(ServiceTCCLInterceptor.java:53) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.eclipse.gemini.blueprint.service.importer.support.LocalBundleContextAdvice.invoke(LocalBundleContextAdvice.java:57) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:137) at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:124) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:241) at com.sun.proxy.$Proxy2966.getLong(Unknown Source) at com.atlassian.jira.config.properties.JiraProperties$getLong.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:148) at com.onresolve.jira.groovy.jql.ScriptedFunctionClauseFactory.getQuery(ScriptedFunctionClauseFactory.groovy:89) at com.atlassian.jira.jql.query.ContextAwareQueryVisitor.visit(ContextAwareQueryVisitor.java:98) at com.atlassian.jira.jql.query.ContextAwareQueryVisitor.visit(ContextAwareQueryVisitor.java:27) at com.atlassian.query.clause.TerminalClauseImpl.accept(TerminalClauseImpl.java:143) ...Check the full stack trace of this error:
if you find a class started with com.onresolve.jira.groovy which is related to the 3rd party add-on ScriptRunner for Jira, then this KB article is relevant and you can move on to the Solution section
taking the error stack trace above as an example, we can see that there is a class that belongs to this add-on:
1com.onresolve.jira.groovy.jql.ScriptedFunctionClauseFactory.getQuery(ScriptedFunctionClauseFactory.groovy:89
Cause
There is a subscription configured for a filter that is using a JQL query involving scripted functions coming from the add-on ScriptRunner for Jira, and this function is causing the error "service proxy has been destroyed". As a result, the Jira application fails to successfully send the filter subscription emails to the users who subscribed to this filter, due to the error.
While the exact root cause of this issue is not entirely clear, the ScriptRunner team is currently investigating the error "service proxy has been destroyed" issue in this public bug ticket: https://productsupport.adaptavist.com/browse/SRJIRA-6234
ℹ️ Please note that this "service proxy has been destroyed" error might have other impacts on the Jira application as described in the KB article Automation for Jira Data Center - All rules are failing to be executed due to the error "service proxy has been destroyed".
Solution
Perform a rolling start of all the Jira nodes in case of a cluster of nodes (or simply restart the Jira application in case of a single node environment).
Was this helpful?