|
||||||||
|
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
I've made the change in winp 1.19 to be more intelligent about overwriting the file.
Historically winp uses timestamp based up-to-date check, but because remoting uses timestamp of jar files for LRU checks, this overwrite check was broken. In 1.19 I've switched to checksum-based up-to-date check, which resolves the problem.
But as I was doing that, I noticed a deeper issue here. "Native Library ...\winp.x64.dll already loaded in another classloader " is likely because JNLP slave is retrying after it lost a connection with the master. During the previous connection, the slave has loaded one copy of winp.dll, and after reconnection it's trying to load one more, which is obviously failing.
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.
This has been a long standing TODO, but it's a good change as it would prevent memory leak and static state clutter over time.