Make JenkinsHTTPClient timeouts configurable

[seejaybee]

in some cases, reading the Jenkins Job Status times out. It seems that the timeout is pretty short. Effect is, that instead of Job Infos, an exclamation mark is shown.

[MarkusTiede]

IMHO the hard-coded timeouts should be somehow configurable:

[...]
public class JenkinsHttpClient {
	private static final int SO_TIMEOUT_IN_MILLISECONDS = 3000;
	private static final int CONNECTION_TIMEOUT_IN_MILLISECONDS = 500;
[...]

[greg-junkietech]

The time is spent on the Confluence server while executing the macro, as long as the Jenkins node has to serve the data for one light (no AJAX).
This impacts the Confluence page loading time, that the user has to wait to see something in his browser. With multiple lights on a dashboard, it can become drastically long, especially if the timeout behind each light is increased.
For that reason I discourage increasing these timeouts. This would just tackle the symptom punctually for users who then need to be (very) patient. And not resolve the problem of slow Jenkins node.
OK for you to close this issue?

[MarkusTiede]

Thanks Greg for explaining: Agreeing against increasing the timeouts; however it might still be useful to have these configurable.

Therefore I`d like to leave the issue open.

[seejaybee]

No, not ok to Close
We need to see the effect. Maybe (and hopefully) confluence runs a parallel way to fill the macro Contents, and the point is, that some jobs on the same node do show correct results, others don't. Lets investigate a bit further

[greg-junkietech]

The effect is clear before it is implemented. And forget it about "a parallel way (for Confluence) to fill the macro Contents", the macro execution happens in one thread on the server by design...
If you really cannot give up, though, please dont make this configurable as macro parameters but as plugin config parameters, that the Confluence Administrator can manage. An example exists on branch feature/jira.

[bsolar17]

Maybe we should investigate asynchronous macros: https://community.atlassian.com/t5/Answers-Developer-Questions/Asynchronous-Confluence-Macro/qaq-p/546874

[greg-junkietech]

If re-implementing the whole logic is an (pretty ultimate) option, Id consider writing it in Javascript to get it executed on the client, with periodic AJAX calls to the Jenkins node to refresh the status transparently for the user.
Such an implementation exists on the baloise branch for the neo4j-speedometer macro.