Opening Issues timing out only in particular project

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?

1 answer

This widget could not be displayed.

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

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)

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.

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

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 :) 

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Published Jul 25, 2018 in Marketplace Apps

Jira Cloud and Bitbucket Cloud Integration with Microsoft Teams

One of the newest products in the Microsoft family - Microsoft Teams,  is a chat-based hub for teamwork that integrates all the people, content, and tools your team needs to be more engaged and ...

733 views 0 3
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you