[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Title: Message Title Pierre-Henri Cazes commented on JENKINS-20913 Re: [jar caching] - winp.x64.dll access conflicts Hi, this issue is reproduced on our servers. Jenkins ver. 1.625.1 : Master on CentOS 6 Node in Windows 7, slave running as service, working !! (ie. NO java.lang.UnsatisfiedLinkError raised with winp dll) Node in Windows 7, slave running via CLA, NOT working (ie. java.lang.UnsatisfiedLinkError raised with winp dll) Node in Windows 8.1, not working in both cases ( as service, or via CLI) Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Title: Message Title Arie Belenky reopened an issue Hi, This issue started to reproduce during the last week on our AWS Windows Server 2012 R2 base machines. Jenkins ver. 1.640 Traceback: SEVERE: I/O error in channel channel java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:82) at hudson.remoting.ChunkedInputStream.readHeader(ChunkedInputStream.java:72) at hudson.remoting.ChunkedInputStream.readUntilBreak(ChunkedInputStream.java:103) at hudson.remoting.ChunkedCommandTransport.readBlock(ChunkedCommandTransport.java:39) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Dec 31, 2015 5:17:38 PM hudson.remoting.Request$2 run SEVERE: Failed to send back a reply java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(Unknown Source) at java.net.SocketOutputStream.write(Unknown Source) at java.io.BufferedOutputStream.flushBuffer(Unknown Source) at java.io.BufferedOutputStream.write(Unknown Source) at hudson.remoting.ChunkedOutputStream.sendFrame(ChunkedOutputStream.java:94) at hudson.remoting.ChunkedOutputStream.drain(ChunkedOutputStream.java:89) at hudson.remoting.ChunkedOutputStream.write(ChunkedOutputStream.java:58) at java.io.OutputStream.write(Unknown Source) at hudson.remoting.ChunkedCommandTransport.writeBlock(ChunkedCommandTransport.java:45) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.write(AbstractSynchronousByteArrayCommandTransport.java:45) at hudson.remoting.Channel.send(Channel.java:582) at hudson.remoting.Request$2.run(Request.java:340) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:62) at java.lang.Thread.run(Unknown Source) Dec 31, 2015 5:17:38 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Terminated Dec 31, 2015 5:17:48 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among https://jenkins.interjunk.com/ Dec 31, 2015 5:17:48 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Handshaking Dec 31, 2015 5:17:48 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to jenkins.interjunk.com:15400 Dec 31, 2015 5:17:48 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Trying protocol: JNLP2-connect Dec 31, 2015 5:17:48 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connected Dec 31, 2015 5:19:00 PM hudson.util.ProcessTree get WARNING: Failed to load winp. Reverting to the default java.lang.UnsatisfiedLinkError: Native Library C:\Users\automation\.jenkins\cache\jars\4A\winp.x64.22D9AB310A3FA2D96B6E03A836A47724.dll already loaded in another classloader at java.lang.ClassLoader.loadLibrary1(Unknown Source) at java.lang.ClassLoader.loadLibrary0(Unknown Source) at java.lang.ClassLoader.loadLibrary(Unknown Source) at java.lang.Runtime.load0(Unknown Source) at java.lang.System.load(Unknown Source) at org.jvnet.winp.Native.loadDll(Native.java:190) at org.jvnet.winp.Native.load(Native.java:122) at org.jvnet.winp.Native.(Native.java:56) at org.jvnet.winp.WinProcess.enableDebugPrivilege(WinProcess.java:212) at hudson.util.ProcessTree$Windows.(ProcessTree.java:494) at hudson.util.ProcessTree.get(ProcessTree.java:345) at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:965) at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:956) at hudson.remoting.UserRequest.perform(UserRequest.java:120) at hudson.remoting.UserRequest.perform(UserRequest.java:48) a
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
SCM/JIRA link daemon commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts Code changed in jenkins User: Kohsuke Kawaguchi Path: core/pom.xml http://jenkins-ci.org/commit/jenkins/4d969004c121bcef07189dfe89fe3347646e741a Log: JENKINS-20913 Use winp 1.19 Updated to a newer version (cherry picked from commit 6b350af44dee8e1e6cad4cce67941b3ebf88ac52) Conflicts: core/pom.xml 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kohsuke Kawaguchi resolved JENKINS-20913 as Fixed [jar caching] - winp.x64.dll access conflicts I'm now marking this issue fixed with winp 1.19. The other part of the issue (of not reusing the same JVM for multiple reconnections to the master) will be tracked in JENKINS-19055, Change By: Kohsuke Kawaguchi (02/Apr/14 12:28 AM) Status: Open Resolved Assignee: Kohsuke Kawaguchi Resolution: Fixed 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kohsuke Kawaguchi commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts This bug is not even marked as fixed yet, so it's way too early to predict LTS backporting plan. We'd first have to fix this in the trunk. Knowing whether the library is already loaded or not doesn't really help either, because if it's loaded through another classloader, we won't be able to reuse currently loaded copy. 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Oleg Nenashev commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Koshuke I've also noticed that I've selected an improper way. The winp-1.19 should resolve the issue. > 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. 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Oleg Nenashev edited a comment on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @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. 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kishore Redlapalli commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Kohsuke, Do we have a rough idea on which LTS release would have this fix. We are using LTS 1.532 on CentOS for our CI which is expected to be online 24x7x365, and we see this issue that seems to pop up on around 30 of our slaves every week or so. @Oleg, we would not want the workaround mentioned since all our slaves are not expected to have any overhead whatsoever due to any other running process. 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kohsuke Kawaguchi commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts I suppose another simple workaround fix would be to copy winp.dll into another file and load it. It'd work around "already loaded in another classloader" problem. 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kohsuke Kawaguchi commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts 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. 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Oleg Nenashev commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts Created a PR, which allows to disable JAR caching via the CLI option https://github.com/jenkinsci/remoting/pull/21 BTW, it is just a workaround. The complete resolution requires some tweaks in the caching procedures. 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Horia Constantin commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Oleg, your latest suggestion worked. The job that runs great for me: using the Startup trigger plugin, triggered for a specific label. But, due to some issues in the Startup trigger plugin, with some tweaking: install manually version 2.4 configure the job "This build is parameterized", with a label parameter (the same label as before) and with "Run on all nodes matching the label" checked. 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Oleg Nenashev updated JENKINS-20913 [jar caching] - winp.x64.dll access conflicts Added the lts-candidate label. The issue makes all Windows process termination flows unreliable Change By: Oleg Nenashev (10/Mar/14 8:41 AM) Labels: classloader lts-candidate remoting windows winp 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Oleg Nenashev commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Horia Constantin It was a my mistake. System Groovy script always executes on the master instead of the target slave. You can use the Scriptler plugin: 1) Create a Scriptler script Write down the groovy call into the script window Allow execution by users having "Run Script Permission" Check that "Run always on master" is disabled 2) Call this script as a build step inside your job 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Horia Constantin commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Oleg I'm following your recommendation: 1) Added a freestyle job triggered via the Startup trigger plugin. 2) In the build section, Execute system Groovy script -> Groovy command 3) Just a single line in that field: hudson.remoting.Engine.current().setJarCache(null) Running the job throws me a "FATAL: Cannot invoke method setJarCache() on null object". Doing a print of hudson.remoting.Engine.current() in the same build job shows it as null. If I do this through "There should be a "Script Console" action on the slave's main page" everything runs fine (and I see that hudson.remoting.Engine.current() is not null). Would you have any idea why this is? 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.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kishore Redlapalli commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts Thanks Oleg, have run it once, will observe if the issue occurs again 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Oleg Nenashev commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Kishore > not sure i can access the URL of the script mentioned There should be a "Script Console" action on the slave's main page > when you say this affects performance of a node, could you be a little specific in terms what would be affected, (network bandwidth or cpu cycles?) The JAR caching will be disabled, so your slave will have do download all classed from the master node. So the first run of jobs/etc may take more time, but all other runs won't be affected. Actually, it affects distributed systems only. 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kishore Redlapalli edited a comment on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Oleg thanks for your response not sure i can access the URL of the script mentioned, can you please check. when you say this affects performance of a node, could you be a little specific in terms what would be affected, (network bandwidth or cpu cycles?) Meanwhile i tried to pass null via "-jar-cache" CLI parameter It is not possible to do so, the slave doesn't launch via jnlp 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kishore Redlapalli commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Oleg thanks for your response not sure i can access the URL of the script mentioned, can you please check. when you say this affects performance of a node, could you be a little specific in terms what would be affected, (network bandwidth or cpu cycles?) 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Oleg Nenashev
commented on JENKINS-20913
[jar caching] - winp.x64.dll access conflicts
Disclaimer: This approach works on my installation (1.509.4), but it actually corrupts the normal flow and may lead to serious classloading issues.
You will need a Groovy plugin...
A simple manual approach:
1) Go ${JENKINS_URL}/computer/${NODE_NAME}/script
2) Call "http://arcjenkinsdev/computer/ru20-hw-farm23/script"
After that, the Jar caching will be disabled till the node's reconnection. Please note that it may affect the performance of node.
In order to setup an automatic cache disabling, just use Startup Trigger together with a System Groovy Script build step.
https://wiki.jenkins-ci.org/display/JENKINS/Startup+Trigger
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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kishore Redlapalli commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Oleg Thanks for your quick response, could you please mention the groovy script that you have told above, this is very predominant in our environment and our ci is going for a toss! 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Murali Devakumar commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Oleg, Thanks for quick response. Can you please be more elaborate on either of options and I am running slave as windows service, which limits me with CLI parameters. 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Oleg Nenashev commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Murali Currently there is no solutions or ETAs. As a workaround, you can disable Jar caching by calling a "hudson.remoting.Engine.current().setJarCache(null)" to disable the cache (e.g. call a System Groovy script on the node). // Probably, it is possible to pass null via "-jar-cache" CLI parameter. 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Murali Devakumar commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts This issue is killing the whole continuous integration process. Do we have any workaround or any time line to get this fixed? 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kishore Redlapalli commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Oleg Not sure how that embedded object got added. We are seeing the same [jar caching] - winp.x64.dll access conflicts mentioned above 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kishore Redlapalli edited a comment on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts We are seeing this on win8/8.1 slaves once in a week!! slave.jar crashes with the above error we are on Jenkins LTS 1.532.1 running on CentOs6.5 also, at the end of each job, the above issue occurs everytime!! 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Oleg Nenashev commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts @Kishore If I understand toy correctly, you see the following issue: Unable to render embedded object: File (..can this be fixed please) not found. If yes, I suppose that this is an another issue. Please create ticket for it 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kishore Redlapalli edited a comment on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts We are seeing this on win8/8.1 slaves once in a week!Unable to render embedded object: File (..can this be fixed please) not found.! slave.jar crashes with the above error we are on Jenkins LTS 1.532.1 running on CentOs6.5 also, at the end of each job, the above issue occurs everytime!! 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kishore Redlapalli edited a comment on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts We are seeing this on win8/8.1 slaves once in a week!Unable to render embedded object: File (..can this be fixed please) not found.! slave.jar crashes with the above error we are on Jenkins LTS 1.532.1 running on CentOs6.5 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/groups/opt_out.
[JIRA] [core] (JENKINS-20913) [jar caching] - winp.x64.dll access conflicts
Kishore Redlapalli commented on JENKINS-20913 [jar caching] - winp.x64.dll access conflicts We are seeing this on win8/8.1 slaves once in a week!Unable to render embedded object: File (..can this be fixed please) not found.! we are on Jenkins LTS 1.532.1 running on CentOs6.5 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/groups/opt_out.
