Child pages
  • Backlog is slow to load
Skip to end of metadata
Go to start of metadata

Problem

The Backlog is slow to load. 

Diagnosis

Environment

  • JIRA 6.1 or 6.2 with JIRA Agile 6.6.60 or higher.
  • A high number of Epic Links present on the board.

Diagnostic Steps

  • Generating a Thread Dump while the board is loading indicates a lock while waiting for a database response:

    "http-bio-8080-exec-18" daemon prio=5 tid=0x00007ff3d097a000 nid=0x7607 runnable [0x000000011a475000]
       java.lang.Thread.State: RUNNABLE
    	at java.net.SocketInputStream.socketRead0(Native Method)
    	at java.net.SocketInputStream.read(SocketInputStream.java:152)
    	at java.net.SocketInputStream.read(SocketInputStream.java:122)
    	at java.io.DataInputStream.readFully(DataInputStream.java:195)
    	at java.io.DataInputStream.readFully(DataInputStream.java:169)
    	at net.sourceforge.jtds.jdbc.SharedSocket.readPacket(SharedSocket.java:842)
    	at net.sourceforge.jtds.jdbc.SharedSocket.getNetPacket(SharedSocket.java:723)
    	- locked <0x00000007a33f0b98> (a java.util.ArrayList)
    	at net.sourceforge.jtds.jdbc.ResponseStream.getPacket(ResponseStream.java:466)
    	at net.sourceforge.jtds.jdbc.ResponseStream.read(ResponseStream.java:103)
    	at net.sourceforge.jtds.jdbc.ResponseStream.peek(ResponseStream.java:88)
    	at net.sourceforge.jtds.jdbc.TdsCore.wait(TdsCore.java:3932)
    	at net.sourceforge.jtds.jdbc.TdsCore.executeSQL(TdsCore.java:1046)
    	- locked <0x00000007f9950fe0> (a net.sourceforge.jtds.jdbc.TdsCore)
    	at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQLQuery(JtdsStatement.java:465)
    	at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeQuery(JtdsPreparedStatement.java:778)
    	- locked <0x00000007a33f0680> (a net.sourceforge.jtds.jdbc.ConnectionJDBC3)
    	at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
    	at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
    	at org.ofbiz.core.entity.jdbc.SQLProcessor.executeQuery(SQLProcessor.java:597)
    	at org.ofbiz.core.entity.GenericDAO.selectListIteratorByCondition(GenericDAO.java:851)
    	at org.ofbiz.core.entity.GenericDAO.selectByAnd(GenericDAO.java:725)
    	at org.ofbiz.core.entity.GenericHelperDAO.findByAnd(GenericHelperDAO.java:150)
    	at org.ofbiz.core.entity.GenericDelegator.findByAnd(GenericDelegator.java:901)
    	at org.ofbiz.core.entity.GenericDelegator.findByAnd(GenericDelegator.java:879)
    	at org.ofbiz.core.entity.GenericDelegator.findByAnd(GenericDelegator.java:848)
    	at com.opensymphony.module.propertyset.ofbiz.OFBizPropertySet.findPropertyEntry(OFBizPropertySet.java:298)
    	at com.opensymphony.module.propertyset.ofbiz.OFBizPropertySet.get(OFBizPropertySet.java:266)
    	at com.opensymphony.module.propertyset.AbstractPropertySet.getLong(AbstractPropertySet.java:247)
    	at com.atlassian.jira.propertyset.JiraCachingPropertySet.getLong(JiraCachingPropertySet.java:424)
    	at com.atlassian.greenhopper.service.PersistenceServiceImpl.getLong(PersistenceServiceImpl.java:63)
    	at com.atlassian.greenhopper.service.properties.PropertyDao.getLongProperty(PropertyDao.java:29)
    	at com.atlassian.greenhopper.service.issuelink.EpicCustomFieldServiceImpl.getDefaultFieldOrNull(EpicCustomFieldServiceImpl.java:181)
    	at com.atlassian.greenhopper.service.issuelink.EpicCustomFieldServiceImpl.getDefaultField(EpicCustomFieldServiceImpl.java:163)
    	at com.atlassian.greenhopper.service.issuelink.EpicCustomFieldServiceImpl.getDefaultEpicLinkField(EpicCustomFieldServiceImpl.java:85)
    	at com.atlassian.greenhopper.web.rapid.issue.fields.EpicLinkFieldEntryFactory.createViewEntry(EpicLinkFieldEntryFactory.java:57)
    	at com.atlassian.greenhopper.web.rapid.issue.fields.EpicLinkFieldEntryFactory.createViewEntry(EpicLinkFieldEntryFactory.java:23)
    	at com.atlassian.greenhopper.web.rapid.list.ExtraFieldsHelper.renderField(ExtraFieldsHelper.java:136)
    	at com.atlassian.greenhopper.web.rapid.list.ExtraFieldsHelper.renderField(ExtraFieldsHelper.java:105)
    	at com.atlassian.greenhopper.web.rapid.list.EpicCallbackComponent.processFieldData(EpicCallbackComponent.java:49)
    	at com.atlassian.greenhopper.web.rapid.list.RapidIssueEntryCallback.createVisibleEntry(RapidIssueEntryCallback.java:249)
    	at com.atlassian.greenhopper.web.rapid.list.RapidIssueEntryCallback.fieldData(RapidIssueEntryCallback.java:207)
    	at com.atlassian.greenhopper.service.issue.callback.AbstractCompoundDataCallback.issueComplete(AbstractCompoundDataCallback.java:45)
    	at com.atlassian.greenhopper.service.issue.callback.ComposedIssueDataCallback.issueComplete(ComposedIssueDataCallback.java:75)
    	at com.atlassian.greenhopper.service.issue.IssueDataCollector.collect(IssueDataCollector.java:86)
    	at com.atlassian.greenhopper.service.issue.IssueDataCollector.collect(IssueDataCollector.java:58)
    	at com.atlassian.jira.issue.search.providers.LuceneSearchProvider.searchAndSort(LuceneSearchProvider.java:478)
    	at com.atlassian.jira.issue.search.providers.LuceneSearchProvider.searchAndSort(LuceneSearchProvider.java:179)
    	at sun.reflect.GeneratedMethodAccessor574.invoke(Unknown Source)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.lang.reflect.Method.invoke(Method.java:606)
    	at com.atlassian.plugin.osgi.hostcomponents.impl.DefaultComponentRegistrar$ContextClassLoaderSettingInvocationHandler.invoke(DefaultComponentRegistrar.java:129)
    	at com.sun.proxy.$Proxy265.searchAndSort(Unknown Source)
    	at sun.reflect.GeneratedMethodAccessor574.invoke(Unknown Source)
    	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.lang.reflect.Method.invoke(Method.java:606)
    	at com.atlassian.plugin.osgi.bridge.external.HostComponentFactoryBean$DynamicServiceInvocationHandler.invoke(HostComponentFactoryBean.java:154)
    	at com.sun.proxy.$Proxy265.searchAndSort(Unknown Source)
    	at com.atlassian.greenhopper.service.issue.IssueDataServiceImpl.findImpl(IssueDataServiceImpl.java:156)
    	at com.atlassian.greenhopper.service.issue.IssueDataServiceImpl.findAndSortWithServiceOutcome(IssueDataServiceImpl.java:63)
    	at com.atlassian.greenhopper.web.rapid.list.RapidIssueEntryQueryServiceImpl.collectIssues(RapidIssueEntryQueryServiceImpl.java:713)
    	at com.atlassian.greenhopper.web.rapid.list.RapidIssueEntryQueryServiceImpl.collectPlanModeIssues(RapidIssueEntryQueryServiceImpl.java:361)
    	at com.atlassian.greenhopper.web.rapid.plan.PlanningModeServiceImpl.getBacklogIssuesAndSprintAssignment(PlanningModeServiceImpl.java:96)
    	at com.atlassian.greenhopper.web.rapid.plan.PlanningModeHelper.loadNewBacklogData(PlanningModeHelper.java:123)
    	at com.atlassian.greenhopper.web.rapid.plan.PlanningModeResource$1.call(PlanningModeResource.java:95)
    	at com.atlassian.greenhopper.web.rapid.plan.PlanningModeResource$1.call(PlanningModeResource.java:84)
    	at com.atlassian.greenhopper.web.util.RestCall.response(RestCall.java:42)
    	at com.atlassian.greenhopper.web.AbstractResource.createResponse(AbstractResource.java:100)
    	at com.atlassian.greenhopper.web.AbstractResource.response(AbstractResource.java:81)
    	at com.atlassian.greenhopper.web.rapid.plan.PlanningModeResource.getBacklogData(PlanningModeResource.java:83)
    	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  • Looking at the Network tab in Google Chrome's Developer Tools shows a large amount of time spent on the /rest/greenhopper/1.0/xboard/plan/backlog request:

Cause

  • The main suspicion at the moment is that JIRA Agile is running a lot of SQL requests that are holding up the threads while loading the Backlog. A more efficient way to handle this is currently being tracked as part of  GHS-6925 - Getting issue details... STATUS  and  GHS-10819 - Getting issue details... STATUS .

 

Resolution

  • JIRA 6.3 or later has been noted to improve the performance when loading the Backlog
Help us improve!

6 Comments

  1. Wow. I have some remarkable numbers to share. We have JIRA 6.2.7 with Agile 6.6.70, and our instance grinds to a halt when multiple teams are doing their standups. On a staging instance, I chose a particular board that has lots of epics and turned on SQL logging. When I load the backlog view with Agile 6.6.51, there are 80 SELECT statements. When I load the same view with Agile 6.6.70, there are 1915 SELECT statements. We're not quite ready to upgrade to JIRA 6.3/6.4, so we'll be downgrading to Agile 6.6.51 shortly.

    1. And that was the Epic Lozenges right?

      Also the article saysL "JIRA 6.3 or later has been noted to improve the performance when loading the Backlog". Do you have a JIRA issue that relates to why that might be so?

      1. We don't have a more link or issue more specific than the JIRA Agile tickets above as yet.  Most likely something changed regarding caching in JIRA 6.3 and the elimination of this problem is a side effect.

    2. David Marshall did the downgrade of JIRA Agile work for you?

      1. It did, but we shortly upgraded to 6.3.15, so it became moot.

        1. Thanks for the quick reply (thumbs up).  The backlog spinner is killing us... just trying to buy a few weeks to prep for 6.3.15.