Request to replace IWorkItemRestService/workItemDTO2 with Reportable REST Service
ecos-files opened this issue · comments
The overhead of composing history for display using WorkItemRestService/workItemDTO2 can be noticeable when the history is very large and contains HTML attributes. If the status history presentation appears on the overview page the history is loaded even when the history tab is not opened. The Presentation.js currently loads the history using XHRGet to the url:
"service/com.ibm.team.workitem.common.internal.rest.IWorkItemRestService/workItemDTO2?id="
+ workItemId
+ "&includeAttributes=false"
+ "&includeLinks=false"
+ "&includeApprovals=false"
+ "&includeHistory=true"
+ "&includeLinkHistory=false";
This provides the history but includes the parsing and comparison of history, which can cause a delay loading the work item. The parsing and comparison of full history are not needed by the tool. Instead the work item states containing the historyItems containing the status change, or by looking at the state transitions in the "current state" XML.
The reportable rest service can be used to load the item history of states:
Fetching item history (faster)
https: test.ibm.com:9443/ccm/rpt/repository/workitem?fields=workitem/workItem[id=1]/(id|priority|itemHistory/*)
The state transitions are in a section in the "current state". Fetching state transitions (fastest)
https: test.ibm.com:9443/ccm/rpt/repository/workitem?fields=workitem/workItem[id=1]/(id|priority|itemHistory/*|state/*|stateTransitions/*|stateTransitions/targetStateId/*|stateTransitions/changedBy/*/*)
... for reference the rest of the work item can be loaded by adding |* at the end of the url...
https: test.ibm.com:9443/ccm/rpt/repository/workitem?fields=workitem/workItem[id=1]/(id|priority|itemHistory/*|*)
https: test.ibm.com:9443/ccm/rpt/repository/workitem?fields=workitem/workItem[id=1]/(id|priority|itemHistory/*|state/*|stateTransitions/*|stateTransitions/targetStateId/*|stateTransitions/changedBy/*/*|*)
The /rpt requests return the XML of the state which can be either parsed into a document (expensive) or searched for the desired elements. The /rpt url ?fields should be tuned, such to enumerate the desired data rather than using /* to load all data. For example use |... /itemHistory/modifiedBy/* rather than /itemHistory/*. The goal should be load the minimal data needed.
The reportable REST service API should improve server performance. Excluding loading the description and HTML attributes will reduce the payload size and improve document parsing performance and memory on the client. Thank you.
Team - is anyone looking this issue? Can this be fixed ASAP as this is causing an outage in the CCM live server.
@MartinBenninger any thoughts about fixing this issue? :)
We are also using this plugin but facing expensive load when a Work Item has a long and big history. This load causes CCM server to be unresponsive and requires a restart to fix it.
To work around this issue we need to shrink the history of all Work Items to a small value (e.g. 5) which can be done through Advanced Properties.
Greetings,
Simon
@MartinBenninger any thoughts about fixing this issue? :) We are also using this plugin but facing expensive load when a Work Item has a long and big history. This load causes CCM server to be unresponsive and requires a restart to fix it.
To work around this issue we need to shrink the history of all Work Items to a small value (e.g. 5) which can be done through Advanced Properties.
Greetings, Simon
Hello Simon,
Martin is not available.
We are aware of this sub-optimal implementation of the Status History and will work on it in near future.
But the rootcause is at IBM side. Same issue happens also on the history tab of a Work Item. RTC does not scale well at this point. Reading one history entry needs about a half of a second!!
We had several Cases open at IBM against the bad implementation of history load. But because its "working" its not a defect according IBM.
At the end the result is, we had to create Ideas as Feature Request.
One big wish is, that all customers create cases against CCM history load implementation. Maybe this would motivate IBM to solve the root cause.
Btw. CMM becomes unresponsive because of a lot of paralell services running and!reading history. Waiting long enough until they!are finished solves the CCM unrespondsiveness without a reboot.
regards
Guido
Team - is anyone looking this issue? Can this be fixed ASAP as this is causing an outage in the CCM live server.
- because this is open source anyone can contribute with a refactored version
- the "outage" of CCM is also on the history tab without this presentation. So its!an IBM RTC/EWM issue and should be reported as case there.
- we will contribute a new version soon
@MartinBenninger any thoughts about fixing this issue? :) We are also using this plugin but facing expensive load when a Work Item has a long and big history. This load causes CCM server to be unresponsive and requires a restart to fix it.
To work around this issue we need to shrink the history of all Work Items to a small value (e.g. 5) which can be done through Advanced Properties.
Greetings, SimonHello Simon,
Martin is not available.
We are aware of this sub-optimal implementation of the Status History and will work on it in near future.
But the rootcause is at IBM side. Same issue happens also on the history tab of a Work Item. RTC does not scale well at this point. Reading one history entry needs about a half of a second!!
We had several Cases open at IBM against the bad implementation of history load. But because its "working" its not a defect according IBM. At the end the result is, we had to create Ideas as Feature Request.
One big wish is, that all customers create cases against CCM history load implementation. Maybe this would motivate IBM to solve the root cause.
Btw. CMM becomes unresponsive because of a lot of paralell services running and!reading history. Waiting long enough until they!are finished solves the CCM unrespondsiveness without a reboot.
regards Guido
I agree in everything @schneigu
the root cause is related in IBMs way of working with history - I have already a ticket (the second one) open for this issue. When disabling the Status History Extension, and opening just 3 or 4 Work Items with the heavy History on their history tab, the same behaviour appears and the server gets unresponsive.
I also agree that the server comes back after the items are loaded, but: In our case this took more than half an hour which is not suitable to do nothing. And - our users are so hard working in parallel that they just open more than the noted 3 or 4 workitems in several tabs. The user I've talked to opened more than 10 in several tabs (due to a query this was working quick enough before the server got unresponsive), which means it won't come back in 3 hours
Greetings,
Simon
We analyzed the code and we do most already with the reportable API like requested above.
The call for WorkItemRestService/workItemDTO2 is only used for the ToolTip on the Statechange, showing details about the change done, but this is called at beginning to prepare all tooltips of all statechanges.
We are discussing to get rid of this tooltip at all or have a possibility to lazy load on an event on one status change.
Or other option could be having a configuration property to disable/enable the tooltip.
What's your opinion? Does your user relay on the tooltip?
cheers
Guido
We analyzed the code and we do most already with the reportable API like requested above.
The call for WorkItemRestService/workItemDTO2 is only used for the ToolTip on the Statechange, showing details about the change done, but this is called at beginning to prepare all tooltips of all statechanges.
We are discussing to get rid of this tooltip at all or have a possibility to lazy load on an event on one status change. Or other option could be having a configuration property to disable/enable the tooltip.
What's your opinion? Does your user relay on the tooltip?
cheers Guido
Tooltip is always nice to have. But to be honest - I never used it and I don't think the users internally are relying on it.
So I would vote for making it removeable. Changing the current mode to lazy loading would also be a good option. Users who relying on it would still get this information and others are not bothered by background stability effects.
So - customizable (on / off) with lazy load when on would be the best of the best in my opinion
Thanks for a new version fixing this issue - I will take a look at it today or later this week :)