Details
-
Bug
-
Resolution: Unresolved
-
Medium
-
None
-
5.4.1, 5.9.7
-
11
-
Severity 2 - Major
-
1
-
Description
I can't see any timeout configuration for app-links but this perhaps could be part of the solution.
On a recent EAC outage we see a lot of heap being used by responses from JIRA, and we also see responses taking an increasing length of time to come back.
This graph is interesting. The 9:50am spike in throughput seems to lead to a ramp up in GC activity. Perhaps related to JIRA responses being large or our processing of them inefficient in object creation (see CONF-32067). Response times look reasonable at this point.
Then around 10:02am response times start to really spike and throughput drops. It looks like this results in an outage to EAC users at this point. These long lived calls may also be contributing to the GC pain as objects are hanging around too long and surviving too many GC sweeps.
I think we need a way to both limit how many concurrent JIRA connections we allow and to timeout them out where necessary.
Doing this in conjunction with the other 'coathanger' integrations, such as the JIRA issues header would be really nice. At the moment trying to throttle and manage the connections from Confluence to JIRA is very difficult.
Attachments
Issue Links
- relates to
-
CONFSERVER-32525 Pages/Blogs timeout if they contain too many JIRA Issues Macros
- Closed