Opening Issues timing out only in particular project

[Leena Bakshi]

I have one project where we have generic issues like PTO, Meetings, General etc, wherein any jira user can log time if they were on PTO and things like that. 

Now the issue is that when we try to open this issue, wheel keeps going and then the popup window comes with Request timed out. The only thing that I noticed is that these issues which are timing out have 62 years or 19 years or 7 years of time logged in. I am not sure if thats what causing it or something else.

Has anyone come across this kind of issue too?

[somethingblue]

Hi Leena,

• What are you using for Time Tracking, e.g. Tempo add-on, JIRA, etc?
• Is this a Server or Cloud instance

If this is a server instance, when you try to open the issue can you tell me what you see in the Catalina.out logs and the atlassian-jira.log?

Let's start with that and we'll go from there.

Cheers,

Branden

[Leena Bakshi]

HI Branden,

We are using Tempo in On Prem instance ( jira 7.3.3).

This is what I see in Atlassian Jira log:

https-jsse-nio-443-exec-43 ERROR leena.bakshi 969x1682432x2 1yfjxfr 172.18.188.143 /browse/AD-2 [c.a.p.webresource.assembler.DefaultWebResourceAssembler] Error generating bigpipe content for 'activity-panel-pipe-id': Deadline exceeded
java.lang.RuntimeException: Deadline exceeded
at com.atlassian.plugin.webresource.bigpipe.QueueFutureCompletionService.forceCompleteAll(QueueFutureCompletionService.java:62)
at com.atlassian.plugin.webresource.bigpipe.BigPipe.forceCompleteAll(BigPipe.java:33)
at com.atlassian.plugin.webresource.assembler.DefaultWebResourceAssembler$1.drainBigPipe(DefaultWebResourceAssembler.java:116)
at com.atlassian.plugin.webresource.assembler.DefaultWebResourceAssembler$1.resolve(DefaultWebResourceAssembler.java:94)
at com.atlassian.plugin.webresource.assembler.DefaultWebResourceAssembler$1.drainOrPoll(DefaultWebResourceAssembler.java:75)
at com.atlassian.plugin.webresource.assembler.DefaultWebResourceAssembler$1.drainIncludedResources(DefaultWebResourceAssembler.java:66)
at com.atlassian.jira.web.pagebuilder.AbstractJspDecorator.writeOnFlush(AbstractJspDecorator.java:58)
at com.atlassian.jira.web.pagebuilder.DefaultPageBuilder.flush(DefaultPageBuilder.java:87)
at com.atlassian.jira.web.pagebuilder.DefaultPageBuilder.finish(DefaultPageBuilder.java:112)
... 21 filtered
at com.atlassian.jira.projects.legacy.LegacyRedirectFilter.handleErrorExtractingUrlComponents(LegacyRedirectFilter.java:89)
at com.atlassian.jira.projects.legacy.LegacyRedirectFilter.doFilter(LegacyRedirectFilter.java:61)
... 15 filtered
at com.atlassian.jira.security.JiraSecurityFilter.lambda$doFilter$0(JiraSecurityFilter.java:80)
... 1 filtered
at com.atlassian.jira.security.JiraSecurityFilter.doFilter(JiraSecurityFilter.java:78)
... 36 filtered
at com.atlassian.jira.servermetrics.CorrelationIdPopulatorFilter.doFilter(CorrelationIdPopulatorFilter.java:30)
... 5 filtered
at com.atlassian.servicedesk.internal.web.CustomerContextSettingFilter.lambda$invokeFilterChain$0(CustomerContextSettingFilter.java:181)
at com.atlassian.servicedesk.internal.utils.context.ReentrantThreadLocalBasedCodeContext.rteInvoke(ReentrantThreadLocalBasedCodeContext.java:134)
at com.atlassian.servicedesk.internal.utils.context.ReentrantThreadLocalBasedCodeContext.runOutOfContext(ReentrantThreadLocalBasedCodeContext.java:87)
at com.atlassian.servicedesk.internal.utils.context.CustomerContextServiceImpl.runOutOfCustomerContext(CustomerContextServiceImpl.java:64)
at com.atlassian.servicedesk.internal.web.CustomerContextSettingFilter.outOfCustomerContext(CustomerContextSettingFilter.java:174)
at com.atlassian.servicedesk.internal.web.CustomerContextSettingFilter.doFilterImpl(CustomerContextSettingFilter.java:130)
at com.atlassian.servicedesk.internal.web.CustomerContextSettingFilter.doFilter(CustomerContextSettingFilter.java:121)
... 4 filtered
at com.atlassian.jwt.internal.servlet.JwtAuthFilter.doFilter(JwtAuthFilter.java:32)
... 8 filtered
at com.atlassian.web.servlet.plugin.request.RedirectInterceptingFilter.doFilter(RedirectInterceptingFilter.java:21)
... 4 filtered
at com.atlassian.web.servlet.plugin.LocationCleanerFilter.doFilter(LocationCleanerFilter.java:36)
... 7 filtered
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:232)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:209)
at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:88)
at net.bull.javamelody.JiraMonitoringFilter.doFilter(JiraMonitoringFilter.java:134)
... 25 filtered
at com.atlassian.jira.servermetrics.MetricsCollectorFilter.doFilter(MetricsCollectorFilter.java:25)
... 29 filtered
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

[Leena Bakshi]

And in catalina log I see the following with repetition:

19-Jan-2018 16:10:03.352 WARNING [https-jsse-nio-443-exec-39] com.sun.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI https://jira.cfins.com/rest/issueNav/1/issueTable, contains form parameters in the request body but the request body has been consumed by the servlet or a servlet filter accessing the request parameters. Only resource methods using @FormParam will work as expected. Resource methods consuming the request body by other means will not work as expected.

19-Jan-2018 16:10:03.602 WARNING [https-jsse-nio-443-exec-32] com.sun.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI https://jira.cfins.com/rest/issueNav/1/issueTable/stable, contains form parameters in the request body but the request body has been consumed by the servlet or a servlet filter accessing the request parameters. Only resource methods using @FormParam will work as expected. Resource methods consuming the request body by other means will not work as expected.

19-Jan-2018 16:10:11.290 WARNING [https-jsse-nio-443-exec-41] com.sun.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI https://jira.cfins.com/rest/jddap/1.0/attachment, contains form parameters in the request body but the request body has been consumed by the servlet or a servlet filter accessing the request parameters. Only resource methods using @FormParam will work as expected. Resource methods consuming the request body by other means will not work as expected.

19-Jan-2018 16:10:15.056 WARNING [https-jsse-nio-443-exec-58] com.sun.jersey.spi.container.servlet.WebComponent.filterFormParameters A servlet request, to the URI https://jira.cfins.com/rest/activity-stream/1.0/preferences?_=1516396214291, contains form parameters in the request body but the request body has been consumed by the servlet or a servlet filter accessing the request parameters. Only resource methods using @FormParam will work as expected. Resource methods consuming the request body by other means will not work as expected.

[somethingblue]

Hi Leena,

The error you're seeing is probably no related to that issue as that appears to be related to Service Desk and the way it was upgraded.  Take a look at JRASERVER-64095 and the workaround for that:

Workaround

Disable BigPipe. That will revert to pre 7.2 page rendering behaviour:

• View Issue is going to take longer to load as big-piped panels (e.g.: Comments section, Projects Sidebar) will be rendered eagerly rather than postponed.

Steps:

1. Navigate to http:<JIRA-base-URL>/secure/admin/SiteDarkFeatures!Default.jspa to get to the Dark Features page.

2. Enable the dark feature com.atlassian.jira.config.BIG_PIPE_KILLSWITCH

Since those are the only errors you're seeing try the above workaround and see if that does indeed help.

In regards to the messages in Catalina.out, you can ignore those but please vote on JRASERVER-59898.  There is a workaround to get rid of those messages as well:

Workaround

Change the logging level for the com.sun.jersey.spi.container.servlet.WebComponent class in the conf/logging.properties file by adding this line:

com.sun.jersey.spi.container.servlet.WebComponent.level = SEVERE

This will prevent the Warnings from being logged.

Try the above workaround for the BIG_PIPE_KILLSWITCH and let us know.

Cheers,

Branden

[Leena Bakshi]

Thanks Branden, just to let you know I did try to upgrade my service desk staright from 2.5.9 to 3.4.1 however then I started seeing errors like unable to render elements due to an error occured.. TO fix that I setup a diff environment (current jira instance) and upgraded jira from 6.4.12 to 7.0.0 and Service desk from 2.5.9 to 3.0.0 and then jira to 7.3.3 and service desk to 3.4.1 . ... So as far as the upgrade path is concerned, I def worked on that and took care of it, however as far as the workaround is concerned  about Enabling "Dark Feature", can it potentially impact anything else?  Because it took us around a month to get everything stabilized after the upgrade :)