-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request to replace IWorkItemRestService/workItemDTO2 with Reportable REST Service #17
Comments
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? :) 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, |
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. 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 |
|
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, |
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. What's your opinion? Does your user relay on the tooltip? cheers |
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 - 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 :) |
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.
The text was updated successfully, but these errors were encountered: