Atlassian Connector for Eclipse
  1. Atlassian Connector for Eclipse
  2. PLE-1516

Performance improvement - get all data with jql search instead of separate calls for every issue

    Details

    • Type: Task Task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.2.1
    • Fix Version/s: 3.3
    • Component/s: None
    • Labels:
      None

      Description

      Unfortunately it is not possible to get all issue data in one jql call before JIRA 5.2.6 because of this bug: https://jira.atlassian.com/browse/JRA-31418
      Older versions does not allow to expand issue details for JQL search (editmeta expando does not work).
      We would need to handle older JIRA versions separately but it would be a maintenance overhead.

      Other solutions:

      1. only JQL call (no separate issue call) and grab as much data as we can during search and retrieve details when issue is being opened (we would need to check if missing data is OK for the TaskList - we miss transitions and editmeta)
      2. JQL call and separate issue call but only first time when details are missing (subsequent call will ask only for JQL results and no separate issue calls), fresh issue details retrieved when issue is being opened

      Wrt 1, unfortunately it does not work because partial issue is considered as different than full issue and Mylyn marks it as changed (not read marker on the Task List and "issue changed" marker in the Issue Editor).

      Wrt 2, it could be difficult because we build issue object every time it is retrieved. It would require non trivial changes.

      My current proposal: get issues in bulk with jql search and if they lack edit meta (for JIRA prior to 5.2.6) then get details with separate call (one per issue as it is in current implementation).
      That is quite easy to implement and we will reduce performance significantly for JIRA 5.2.6 and newer.

        Issue Links

          Activity

          Hide
          Jacek Jaroczynski added a comment -

          Unfortunately due to https://jira.atlassian.com/browse/JRA-34471 this issue cannot be fixed.

          I finished implementation and it appeared that missing attachments information from the bulk query is a blocker due to Mylyn architecture.

          Here is short overview how it works:

          • after bulk synchronization Mylyn stores all task data locally (without attachments information)
          • when user opens the task, its fresh information is retrieved from the server and if not changed (our implementation) then task data from the task list (local storage) is displayed (without attachments)

          We could change "not changed" implementation and always say it has changed but this way all open task editors would get notification and display "refresh editor to..." information.

          It is not possible to force Mylyn to store data retrieved for single task over data retrieved from bulk query.

          There is also "partial" concept. We could mark all tasks retrieved in bulk as partial but this way open editor is not refreshed and does not get information about changes if any - again we lose existing functionality.

          I will commit current state to separate branch. Hopefully JIRA issue will be solved for 6.2 and it will be possible to merge the fix into main branch.

          Show
          Jacek Jaroczynski added a comment - Unfortunately due to https://jira.atlassian.com/browse/JRA-34471 this issue cannot be fixed. I finished implementation and it appeared that missing attachments information from the bulk query is a blocker due to Mylyn architecture. Here is short overview how it works: after bulk synchronization Mylyn stores all task data locally (without attachments information) when user opens the task, its fresh information is retrieved from the server and if not changed (our implementation) then task data from the task list (local storage) is displayed (without attachments) We could change "not changed" implementation and always say it has changed but this way all open task editors would get notification and display "refresh editor to..." information. It is not possible to force Mylyn to store data retrieved for single task over data retrieved from bulk query. There is also "partial" concept. We could mark all tasks retrieved in bulk as partial but this way open editor is not refreshed and does not get information about changes if any - again we lose existing functionality. I will commit current state to separate branch. Hopefully JIRA issue will be solved for 6.2 and it will be possible to merge the fix into main branch.
          Hide
          Jacek Jaroczynski added a comment -

          Rescheduled to 3.3

          Show
          Jacek Jaroczynski added a comment - Rescheduled to 3.3
          Hide
          Robert Munteanu added a comment -

          I think it's feasible to get all the task data in one go and use the partial concept, it's already used in other connectors - I've done it for the Mantis connector. Can't the Jira REST API return just the list of attachments in the JQL call?

          And IIRC the task list only uses the attachment data to decide if there is a remote task context. IMO, even if we lose this, the huge performance gains for large installations will be worth it.

          Show
          Robert Munteanu added a comment - I think it's feasible to get all the task data in one go and use the partial concept, it's already used in other connectors - I've done it for the Mantis connector. Can't the Jira REST API return just the list of attachments in the JQL call? And IIRC the task list only uses the attachment data to decide if there is a remote task context. IMO, even if we lose this, the huge performance gains for large installations will be worth it.
          Hide
          Robert Munteanu added a comment -

          Is there any chance to have this improvement implemented? It would greatly ease the work with Jira and also make the ops team happy

          Show
          Robert Munteanu added a comment - Is there any chance to have this improvement implemented? It would greatly ease the work with Jira and also make the ops team happy

            People

            • Assignee:
              Jacek Jaroczynski
              Reporter:
              Jacek Jaroczynski
            • Votes:
              2 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:

                Who's Looking?