|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
@Koshuke
I've also noticed that I've selected an improper way.
> To properly solve this requires a change in the client (and possibly winsw), so that after losing a connection the slave will have winsw relaunch a new service, so that JVM will start fresh.
I suppose it slightly conflicts with "autonomous slaves" approach (slaves may continue operations on temporary disconnects), which usually appears during the infrastructure reliability discussions.
What about checking if the DLL has been already loaded? http://stackoverflow.com/questions/1007861/how-do-i-get-a-list-of-jni-libraries-which-are-loaded/
I suppose that the slave may just log a warning in such case
@Kishore
I'd prefer to recall the proposed Groovy script above, because it may lead to NPEs on uncached resource loads after restarts or plugin updates.
Such solution should be used only on long-run slaves with "warm up" jobs and without class unloading.