-
Suggestion
-
Resolution: Unresolved
-
None
-
None
-
0
-
3
-
When Confluence is set behind a reverse proxy, and incoming traffic is not allowed, using any internal gadgets opens up a HTTP thread, and clicking on the internal gadgets multiple times will eventually exhaust all HTTP threads, causing Confluence to hang, or crash.
This behavior is similar to CONFSERVER-39393, where when Confluence is unable to access external gadgets, opening up the gadgets causes Confluence to use up it's HTTP threads.
In this case, the issue is fixed by allowing incoming traffic from Confluence server to the load balancer.
The issue is that the errors and symptoms of this issue is similar to CONFSERVER-39393, and as such, it's not immediately apparent what the issue is.
Steps to Reproduce:
- Add a proxy configuration for tomcat in server.xml (e.g. proxyName confluence.xyz where confluence.xyz is a load balancer or webserver).
- On the confluence.xyz loadbalancer, do not permit incoming traffic from the Confluence application server. Confluence will (mostly) still work, except for gadgets.
- On Confluence, click on Insert > Macro. This will cause the page to spin and timeout. Do this 48 times (or whatever your maxThreads is set to).
Result:
- Confluence is no longer accessible and needs reboot. There are errors in the log hinting at what may have happened but it is not immediately clear.
Expected:
- There should be a clearer log message or perhaps add a health check that would fails. The current situation where there is a time-delayed crash after some use is not too easy to debug.
- relates to
-
CONFSERVER-39393 Confluence performance can degrade when JIRA/Bamboo has performance problems due to gadget feed retrieval
- Closed
-
CONFSERVER-54831 Prevent changed Jira Gadget URL from causing threads to stick in Confluence
- Closed