Skip to content
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

Make JenkinsHTTPClient timeouts configurable #14

Open
seejaybee opened this issue Nov 3, 2017 · 7 comments
Open

Make JenkinsHTTPClient timeouts configurable #14

seejaybee opened this issue Nov 3, 2017 · 7 comments

Comments

@seejaybee
Copy link

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
Copy link
Member

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
Copy link
Contributor

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 MarkusTiede changed the title Read timeout when accessing jenkins job Make JenkinsHTTPClient timeouts configurable Nov 3, 2017
@MarkusTiede
Copy link
Member

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
Copy link
Author

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

@MarkusTiede MarkusTiede reopened this Nov 3, 2017
@greg-junkietech
Copy link
Contributor

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
Copy link

bsolar17 commented Nov 3, 2017

@greg-junkietech
Copy link
Contributor

greg-junkietech commented Nov 6, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants