-
Notifications
You must be signed in to change notification settings - Fork 7
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
Comments
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;
[...] |
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). |
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. |
No, not ok to Close |
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... |
Maybe we should investigate asynchronous macros: https://community.atlassian.com/t5/Answers-Developer-Questions/Asynchronous-Confluence-Macro/qaq-p/546874 |
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. |
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.
The text was updated successfully, but these errors were encountered: