Uploaded image for project: 'Jira Service Management Server and Data Center'
  1. Jira Service Management Server and Data Center
  2. JSDSERVER-6715

Adding a comment or creating an issue in a non-JSD project results in JSD PSMQ off thread event handling code kicking in without need.

    XMLWordPrintable

Details

    • 5
    • 1
    • We collect Jira Service Desk feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

    Description

      Issue Summary

      Adding a comment on an issue or creating an issue in a none Java Service Desk project while Service Desk is installed on Jira, results in JSD PSMQ off thread event handling code kicking in and processing the event.
      The PSMQ code is executed without an obvious need in case the project is a Jira Software or a Jira Core.
      This could result is increased database pressure due to the amount of queries hitting the PSMQ tables and could also increase the pressure on the SdOffThreadEventJobRunner thread pool.

      Steps to Reproduce

      1. On Jira Software install Jira Service Desk
      2. Create a Jira Software KANBAN project and create an issue inside it.
      3. Enable debug logging on the package com.querydsl
      4. Add a comment to the above issue.

      Expected Results

      Since we are adding a comment to a KANBAN issue, no Jira Service Desk code should be executed.

      Actual Results

      Jira Service DESK PMSQ code is executed and queries are being sent to the JSD AO_319474_QUEUE and AO_319474_MESSAGE tables.

      Note

      The below logs are seen in the atlassian-jira.log, in this case case SdOffThreadEventJobRunner threads generated 80 different queries for a single comment (Select/Update):

      sabdelfattah@ulmo ~/deployments/jira850/jira-home/log $ grep "/rest/api/2/issue/KAN-14/comment" atlassian-jira.log |grep SdOffThreadEventJobRunner |wc -l
      80
      
      sabdelfattah@ulmo ~/deployments/jira850/jira-home/log $ grep "/rest/api/2/issue/KAN-14/comment" atlassian-jira.log |grep SdOffThreadEventJobRunner |head
      2020-01-21 15:04:37,940 SdOffThreadEventJobRunner:thread-3 DEBUG sherif 904x184x1 xhb8zs 0:0:0:0:0:0:0:1 /rest/api/2/issue/KAN-14/comment [c.querydsl.sql.AbstractSQLQuery] select "AO_319474_QUEUE"."CLAIMANT", "AO_319474_QUEUE"."CLAIMANT_TIME", "AO_319474_QUEUE"."CREATED_TIME", "AO_319474_QUEUE"."ID", "AO_319474_QUEUE"."MESSAGE_COUNT", "AO_319474_QUEUE"."MODIFIED_TIME", "AO_319474_QUEUE"."NAME", "AO_319474_QUEUE"."PURPOSE", "AO_319474_QUEUE"."TOPIC" from "public"."AO_319474_QUEUE" "AO_319474_QUEUE" where "AO_319474_QUEUE"."NAME" = ? limit ?
      2020-01-21 15:04:37,942 SdOffThreadEventJobRunner:thread-3 DEBUG sherif 904x184x1 xhb8zs 0:0:0:0:0:0:0:1 /rest/api/2/issue/KAN-14/comment [c.querydsl.sql.AbstractSQLQuery] select count(*) from "public"."AO_319474_MESSAGE" "AO_319474_MESSAGE" where "AO_319474_MESSAGE"."QUEUE_ID" = ? and ("AO_319474_MESSAGE"."CLAIMANT" is null or "AO_319474_MESSAGE"."CLAIMANT" is not null and ("AO_319474_MESSAGE"."CLAIMANT_TIME" is null or "AO_319474_MESSAGE"."CLAIMANT_TIME" < ?))
      2020-01-21 15:04:37,942 SdOffThreadEventJobRunner:thread-3 DEBUG sherif 904x184x1 xhb8zs 0:0:0:0:0:0:0:1 /rest/api/2/issue/KAN-14/comment [c.querydsl.sql.AbstractSQLQuery] select "AO_319474_QUEUE_PROPERTY"."ID", "AO_319474_QUEUE_PROPERTY"."LONG_VALUE", "AO_319474_QUEUE_PROPERTY"."NAME", "AO_319474_QUEUE_PROPERTY"."PROPERTY_TYPE", "AO_319474_QUEUE_PROPERTY"."QUEUE_ID", "AO_319474_QUEUE_PROPERTY"."STRING_VALUE" from "public"."AO_319474_QUEUE_PROPERTY" "AO_319474_QUEUE_PROPERTY" where "AO_319474_QUEUE_PROPERTY"."QUEUE_ID" = ?
      2020-01-21 15:04:37,943 SdOffThreadEventJobRunner:thread-3 DEBUG sherif 904x184x1 xhb8zs 0:0:0:0:0:0:0:1 /rest/api/2/issue/KAN-14/comment [c.q.sql.dml.SQLInsertClause] update "public"."AO_319474_QUEUE" set "CLAIMANT" = ?, "CLAIMANT_TIME" = ? where "AO_319474_QUEUE"."ID" = ? and ("AO_319474_QUEUE"."CLAIMANT" is null or "AO_319474_QUEUE"."CLAIMANT" is not null and "AO_319474_QUEUE"."CLAIMANT_TIME" < ?)
      2020-01-21 15:04:37,945 SdOffThreadEventJobRunner:thread-3 DEBUG sherif 904x184x1 xhb8zs 0:0:0:0:0:0:0:1 /rest/api/2/issue/KAN-14/comment [c.q.sql.dml.SQLInsertClause] update "public"."AO_319474_MESSAGE" set "CLAIMANT" = ?, "CLAIMANT_TIME" = ? where "AO_319474_MESSAGE"."QUEUE_ID" = ? and "AO_319474_MESSAGE"."CLAIMANT" is not null
      2020-01-21 15:04:37,949 SdOffThreadEventJobRunner:thread-3 DEBUG sherif 904x184x1 xhb8zs 0:0:0:0:0:0:0:1 /rest/api/2/issue/KAN-14/comment [c.q.sql.dml.SQLInsertClause] update "public"."AO_319474_QUEUE" set "CLAIMANT_TIME" = ? where "AO_319474_QUEUE"."ID" = ? and ("AO_319474_QUEUE"."CLAIMANT" = ? and "AO_319474_QUEUE"."CLAIMANT_TIME" >= ?)
      2020-01-21 15:04:37,950 SdOffThreadEventJobRunner:thread-3 DEBUG sherif 904x184x1 xhb8zs 0:0:0:0:0:0:0:1 /rest/api/2/issue/KAN-14/comment [c.querydsl.sql.AbstractSQLQuery] select "AO_319474_MESSAGE"."CLAIMANT", "AO_319474_MESSAGE"."CLAIMANT_TIME", "AO_319474_MESSAGE"."CLAIM_COUNT", "AO_319474_MESSAGE"."CONTENT_TYPE", "AO_319474_MESSAGE"."CREATED_TIME", "AO_319474_MESSAGE"."EXPIRY_TIME", "AO_319474_MESSAGE"."ID", "AO_319474_MESSAGE"."MSG_DATA", "AO_319474_MESSAGE"."MSG_ID", "AO_319474_MESSAGE"."MSG_LENGTH", "AO_319474_MESSAGE"."PRIORITY", "AO_319474_MESSAGE"."QUEUE_ID", "AO_319474_MESSAGE"."VERSION" from "public"."AO_319474_MESSAGE" "AO_319474_MESSAGE" where "AO_319474_MESSAGE"."QUEUE_ID" = ? and ("AO_319474_MESSAGE"."CLAIMANT" is null or "AO_319474_MESSAGE"."CLAIMANT" is not null and ("AO_319474_MESSAGE"."CLAIMANT_TIME" is null or "AO_319474_MESSAGE"."CLAIMANT_TIME" < ?)) order by "AO_319474_MESSAGE"."PRIORITY" desc, "AO_319474_MESSAGE"."CREATED_TIME" asc, "AO_319474_MESSAGE"."ID" asc limit ?
      2020-01-21 15:04:37,951 SdOffThreadEventJobRunner:thread-3 DEBUG sherif 904x184x1 xhb8zs 0:0:0:0:0:0:0:1 /rest/api/2/issue/KAN-14/comment [c.querydsl.sql.AbstractSQLQuery] select "AO_319474_MESSAGE_PROPERTY"."ID", "AO_319474_MESSAGE_PROPERTY"."LONG_VALUE", "AO_319474_MESSAGE_PROPERTY"."MESSAGE_ID", "AO_319474_MESSAGE_PROPERTY"."NAME", "AO_319474_MESSAGE_PROPERTY"."PROPERTY_TYPE", "AO_319474_MESSAGE_PROPERTY"."STRING_VALUE" from "public"."AO_319474_MESSAGE_PROPERTY" "AO_319474_MESSAGE_PROPERTY" where "AO_319474_MESSAGE_PROPERTY"."MESSAGE_ID" = ?
      2020-01-21 15:04:37,953 SdOffThreadEventJobRunner:thread-3 DEBUG sherif 904x184x1 xhb8zs 0:0:0:0:0:0:0:1 /rest/api/2/issue/KAN-14/comment [c.q.sql.dml.SQLInsertClause] update "public"."AO_319474_MESSAGE" set "CLAIMANT" = ?, "CLAIMANT_TIME" = ?, "CLAIM_COUNT" = "CLAIM_COUNT" + ? where "AO_319474_MESSAGE"."ID" = ? and "AO_319474_MESSAGE"."QUEUE_ID" = ? and "AO_319474_MESSAGE"."CLAIMANT" is null
      2020-01-21 15:04:37,953 SdOffThreadEventJobRunner:thread-3 DEBUG sherif 904x184x1 xhb8zs 0:0:0:0:0:0:0:1 /rest/api/2/issue/KAN-14/comment [c.q.sql.dml.SQLInsertClause] update "public"."AO_319474_QUEUE" set "MESSAGE_COUNT" = "MESSAGE_COUNT" - ? where "AO_319474_QUEUE"."ID" = ? and "AO_319474_QUEUE"."MESSAGE_COUNT" > ?
      

      The number of queries can become an issue if the instance is big (500k+ issues) and has a large number of concurrent issue updates.
      Many of those queries are update queries on the tables AO_319474_QUEUE and AO_319474_MESSAGE which can cause performance issues if the database is not fast enough.

      Workaround

      No workaround is found for this issue so far.

      Attachments

        Issue Links

          Activity

            People

              esantos2 Elton Santos
              sabdelfattah Sherif Abdelfattah (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Backbone Issue Sync