[JIRA] [windows-slaves] (JENKINS-22692) Jenkins Windows-Slave throwing exception on shutdown causes connection reset issues
Cees Bos commented on JENKINS-22692 Jenkins Windows-Slave throwing exception on shutdown causes connection reset issues We face the same issue. We have a Linux master and a wide range of slaves. We see these issues with Windows slaves connected as Jenkins service. From the Console log of a job: Thu Jul 03 04:35:29 - Delete everything for instance: defaultInst FATAL: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:722) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:167) at sun.proxy.$Proxy55.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:951) at hudson.Launcher$ProcStarter.join(Launcher.java:362) at hudson.plugins.groovy.Groovy.perform(Groovy.java:117) at hudson.plugins.templateproject.ProxyBuilder.perform(ProxyBuilder.java:87) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.Build$BuildExecution.build(Build.java:198) at hudson.model.Build$BuildExecution.doRun(Build.java:159) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:523) at hudson.model.Run.execute(Run.java:1700) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:782) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:185) at java.io.FilterInputStream.read(FilterInputStream.java:133) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read(BufferedInputStream.java:254) at hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:77) at java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2290) at java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2583) at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2593) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1315) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:369) at hudson.remoting.Command.readFrom(Command.java:92) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:71) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) From the jenkins-slave-err.log Jul 03, 2014 4:35:57 AM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.io.FilterInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:77) at java.io.ObjectInputStream$PeekInputStream.peek(Unknown Source) at java.io.ObjectInputStream$BlockDataInputStream.peek(Unknown Source) at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at hudson.remoting.Command.readFrom(Command.java:92) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:71) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) It happens on several slaves. For us there is no reboot involved.
[JIRA] [core] (JENKINS-8358) A disabled project is always DISABLED even is the project is building
Cees Bos commented on JENKINS-8358 A disabled project is always DISABLED even is the project is building Thanks! 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-22758) Jenkins =1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Cees Bos commented on JENKINS-22758 Jenkins =1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) It looks like not only an issue with swarm plugin. We have a number of jnlp slaves, but we don't get them connected anymore. >From the perspective of the slave it shows 'connected', but Jenkins master shows it as still unconnected. We have a Jenkins master on Linux and mix of all kind of slaves. 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-22758) Jenkins =1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Cees Bos edited a comment on JENKINS-22758 Jenkins =1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) It looks like not only an issue with swarm plugin. We have a number of jnlp slaves, but we don't get them connected anymore. >From the perspective of the slave it shows 'connected', but Jenkins master shows it as still unconnected. We have a Jenkins master on Linux and mix of all kind of slaves. In Jenkins you can click on 'Log' for a node, then there is: JNLP agent connected from /10.1.29.228 But the UI still shows it as offline. 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-22758) Jenkins =1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Cees Bos edited a comment on JENKINS-22758 Jenkins =1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) It looks like not only an issue with swarm plugin. Today we did an update to 1.560 (from 1.554). We noticed 2 things: We have a regular restart of the JNLP slaves with a Groovy script executed on the slave itself as soon as the executor is free. Each slave has only 1 executed. There are long running jobs active on the JNLP saves. So normally it waits till the job is completed, then the next item gets executed. But now the restart task got executed right away, and broke the running job. The machine got restarted and then tried to connect again to Jenkins, that fails. We have a number of jnlp slaves, but we don't get them connected anymore. >From the perspective of the slave it shows 'connected', but Jenkins master shows it as still unconnected. We have a Jenkins master on Linux and mix of all kind of slaves. In Jenkins you can click on 'Log' for a node, then there is: JNLP agent connected from /10.1.29.228 But the UI still shows it as offline. 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] [subversion] (JENKINS-22199) Jenkins throwing errors in SCM Polling and Updates with Subversion
Cees Bos commented on JENKINS-22199 Jenkins throwing errors in SCM Polling and Updates with Subversion We currently use the snapshot plugin, and the issues reported in this ticket does not occur anymore. 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-22758) Jenkins =1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin)
Cees Bos updated JENKINS-22758 Jenkins =1.560 breaks Jenkins slave handling / NIO JNLP related (using swarm plugin) Reverting to 1.559 solved the issue for us. Version 1.560 also gave memory issues for us. Java heap kept growing. After the upgrade it grew up to the max value we have set. Jenkins became slower and slower. After downgrade to 1.559 memory usage is now below 1Gb heap. Change By: Cees Bos (25/Apr/14 6:04 PM) Attachment: usedMemory.png 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] [subversion] (JENKINS-22199) Jenkins throwing errors in SCM Polling and Updates with Subversion
Cees Bos commented on JENKINS-22199 Jenkins throwing errors in SCM Polling and Updates with Subversion Is there anything I can help in that? Today we (again) have 3 failing jobs on this issue. 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] [subversion] (JENKINS-22199) Jenkins throwing errors in SCM Polling and Updates with Subversion
Cees Bos commented on JENKINS-22199 Jenkins throwing errors in SCM Polling and Updates with Subversion When is the next release of the subversion-plugin expected? 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] [subversion] (JENKINS-22199) Jenkins throwing errors in SCM Polling and Updates with Subversion
Cees Bos commented on JENKINS-22199 Jenkins throwing errors in SCM Polling and Updates with Subversion I have raised a pull request to fix this issue. Our builds get broken each day because of this. https://github.com/jenkinsci/subversion-plugin/pull/73 Note: above proposed solution is not valid as it searches for a string in the complete path. In case a subfolder has the same name, then that will be removed, which is invalid. 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] [subversion] (JENKINS-22332) StringIndexOutOfBoundsException: String index out of range: -7 when analyzing the changes of an svn:external
Cees Bos created JENKINS-22332 StringIndexOutOfBoundsException: String index out of range: -7 when analyzing the changes of an svn:external Issue Type: Bug Assignee: Unassigned Components: subversion Created: 25/Mar/14 7:41 AM Description: hudson.util.IOException2: revision check failed on http://srv-ind-scrat:8080/repos/bcp/branches/private/cbos/components/xds/src/dbschema at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:189) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:132) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:738) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:899) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:671) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:580) at hudson.model.Run.execute(Run.java:1676) at hudson.matrix.MatrixBuild.run(MatrixBuild.java:304) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) at hudson.model.OneOffExecutor.run(OneOffExecutor.java:43) Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /repos/bcp/!svn/bc/262146/branches/private/cbos/components/xds/src/dbschema failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:386) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:334) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:324) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.logImpl(DAVRepository.java:995) at org.tmatesoft.svn.core.io.SVNRepository.log(SVNRepository.java:1035) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:181) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:967) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:177) ... 12 more Caused by: svn: E175002: REPORT /repos/bcp/!svn/bc/262146/branches/private/cbos/components/xds/src/dbschema failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 28 more Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -7 at java.lang.String.substring(String.java:1949) at java.lang.String.substring(String.java:1916) at hudson.scm.DirAwareSVNXMLLogHandler.handleLogEntry(DirAwareSVNXMLLogHandler.java:90) at org.tmatesoft.svn.core.internal.wc2.compat.SvnCodec$7.receive(SvnCodec.java:167) at org.tmatesoft.svn.core.internal.wc2.compat.SvnCodec$7.receive(SvnCodec.java:164) at org.tmatesoft.svn.core.wc2.SvnReceivingOperation.receive(SvnReceivingOperation.java:78) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.handleLogEntry(SvnRemoteLog.java:199) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository$1.handleLogEntry(DAVRepository.java:950) at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVLogHandler.endElement(DAVLogHandler.java:226) at
[JIRA] [subversion] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials
Cees Bos edited a comment on JENKINS-21785 Check for changes in folders linked via svn:externals fails due to missing credentials We are facing the same issue as soon as there is an update in the svn:external linked folder. At that moment we don't face the issue in the checkout or update, but we face this issue in the log determination. When there is no change in the svn:external linked folder, then there is no issue. 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] [subversion] (JENKINS-21785) Check for changes in folders linked via svn:externals fails due to missing credentials
Cees Bos commented on JENKINS-21785 Check for changes in folders linked via svn:externals fails due to missing credentials We are facing the same issue as soon as there is an update in the svn:external linked folder. At that moment we don't face the issue in the checkout or update, but we face this issue in the log determination. When there is no change in in the svn:external linked folder, then there is no issue. 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-18199) Deadlock during delete of upstream/downstream projects
Cees Bos created JENKINS-18199 Deadlock during delete of upstream/downstream projects Issue Type: Bug Assignee: Unassigned Components: core Created: 04/Jun/13 6:39 PM Description: We had a number of linked projects which could be removed. I opened multiple projects in multiple tabpages and deleted them. I did not get reaction of the server (timeout). Later on all kind of changes to jobs failed. The cron thread was blocked as well, so no new jobs were started. I was able to create a thread dump. Most methods hang on hudson.model.Project.getPublishersList() this is synchronized method. The deadlock message: "Handling POST /jenkins/job/cws-is-junit-l/doDelete : RequestHandlerThread20": waiting to lock Monitor@0x0c447fa8 (Object@0x000747c7aaf0, a hudson/model/FreeStyleProject), which is held by "Handling POST /jenkins/job/prepare-for-is-regressions/doDelete : RequestHandlerThread15" "Handling POST /jenkins/job/prepare-for-is-regressions/doDelete : RequestHandlerThread15": waiting to lock Monitor@0x0b3e3c68 (Object@0x000747ec1378, a hudson/model/FreeStyleProject), which is held by "Handling POST /jenkins/job/cws-is-junit-l/doDelete : RequestHandlerThread20" The 2 jobs are up and downstream jobs of eachother. Project: Jenkins Priority: Critical Reporter: Cees Bos 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] (JENKINS-16635) NPE in XFPanel XFPanelEntry.getNumberOfFailedBuilds
Cees Bos created JENKINS-16635 NPE in XFPanel XFPanelEntry.getNumberOfFailedBuilds Issue Type: Bug Assignee: Julien RENAUT Components: xfpanel Created: 05/Feb/13 8:45 AM Description: In the log on the master we see this in the log: WARNING: Caught exception evaluating: job.numberOfFailedBuilds in /jenkins/view/z-Loadtests%20Panel/headlessdisplay. Reason: java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor1185.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74) at org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java:66) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:146) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.OtherwiseTag.doTag(OtherwiseTag.java:41) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at
[JIRA] (JENKINS-16616) XFPanel update takes long before it reloads
Cees Bos
created JENKINS-16616
XFPanel update takes long before it reloads
Issue Type:
Bug
Assignee:
Julien RENAUT
Components:
xfpanel
Created:
04/Feb/13 9:01 AM
Description:
In the panel this code is used:
new Ajax.PeriodicalUpdater("xfdisplay-dashboard", refreshUrl, {
method: 'get', frequency: refreshTime, decay: 2
});
decay (Number; default is 1): The rate at which the frequency grows when the response received is exactly the same as the previous. The default of 1 means frequency will never grow; override the default if a stale response implies it's worthwhile to poll less often. If decay is set to 2, for instance, frequency will double (2 seconds, 4 seconds, 8 seconds...) each consecutive time the result is the same; when the result is different once again, frequency will revert to its original value.
http://prototypejs.org/doc/latest/ajax/Ajax/PeriodicalUpdater/index.html
We have a refresh rate at 30 seconds.
So first after 30 seconds is it refreshed, but that it takes 1 minute to refresh and then 2 minutes.
The decay should be 1 IMHO
Project:
Jenkins
Priority:
Critical
Reporter:
Cees Bos
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] (JENKINS-15356) NPE caused executor thread death
Cees Bos commented on JENKINS-15356 NPE caused executor thread death This is a blocker for use. We upgraded to 1.487 and now all we see on serveral machines (with 1 executor) the Thread death with this stacktrace. 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
[JIRA] (JENKINS-15356) NPE caused executor thread death
Cees Bos updated JENKINS-15356 NPE caused executor thread death Change By: Cees Bos (26/Oct/12 7:05 AM) Priority: Major Blocker 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
[JIRA] (JENKINS-15356) NPE caused executor thread death
Cees Bos updated JENKINS-15356 NPE caused executor thread death Change By: Cees Bos (26/Oct/12 7:20 AM) Component/s: matrix 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
[JIRA] (JENKINS-14114) CPU on 100% when sending mail
Cees Bos commented on JENKINS-14114 CPU on 100% when sending mail Lately we did not face this issue anymore. We faced this issue with a very large sync-merge (after a very large drop-merge of another team). The commit message of the sync-merge drop-merge contained all committed in the branch. The size of the commit message was more the 1Mb. I guess that change history XML is parsed and that took a lot of time. Maybe it is possible to create a change XML without commit messages itself (only committer info). That makes parsing of the XML much faster. We use SVN. Only thread information I have is in the screenshot attached to this ticket. 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
[JIRA] (JENKINS-13253) Slave connection reset issues since 1.456
Cees Bos commented on JENKINS-13253 Slave connection reset issues since 1.456 We have 90+ slaves. What is the impact of enabling a finer logging level on performance of Jenkins? Now and then we face this issues, so the change of logging level is required for several days I guess to get some information. 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
[JIRA] (JENKINS-13253) Slave connection reset issues since 1.456
Cees Bos commented on JENKINS-13253 Slave connection reset issues since 1.456 Last Friday we faced the same issue with a linux machine (connected via ssh). As far as I know there are no issues in connectivity. All servers we have are Virtual Machines. Where can I find more information / more logging? 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
[JIRA] (JENKINS-13253) Slave connection reset issues since 1.456
Cees Bos commented on JENKINS-13253 Slave connection reset issues since 1.456 The number of jobs failing with this is less now. We use 1.470 at this moment. A specific job fails now and then with this error. The slave is a windows slave connected 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
[JIRA] (JENKINS-14114) CPU on 100% when sending mail
Cees Bos created JENKINS-14114 CPU on 100% when sending mail Issue Type: Bug Assignee: Slide-O-Mix Attachments: extendedmail_publisher.png Components: email-ext Created: 15/Jun/12 8:30 AM Description: Our Jenkins server was on 100% CPU usage. 4 threads were very busy with sending an email. All 4 thread had the same stacktrace, see screenshot. Looks like that lookup of emailadresses is consuming too much CPU. Project: Jenkins Priority: Blocker Reporter: Cees Bos 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
[JIRA] (JENKINS-13609) Lost of the latest build after jenkins restart
[ https://issues.jenkins-ci.org/browse/JENKINS-13609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163550#comment-163550 ] Cees Bos commented on JENKINS-13609: We have a similar issue, that after a restart some jobs do not have history at all anymore But on filesystem of the master there is still a lot of history. For a particular job is has 30 old builds on disk on the master, but in the view there is nothing anymore. Lost of the latest build after jenkins restart -- Key: JENKINS-13609 URL: https://issues.jenkins-ci.org/browse/JENKINS-13609 Project: Jenkins Issue Type: Bug Components: build-publisher, core Reporter: stibbons Assignee: vjuranek Attachments: jenkins.log Hello I have a recuring problem since some weeks, I though this was coming from me... so here is the description: - I have a build which produce junit files to be parsed and included in the results - each night this build run and generates a new build number + artifacts + HTML report + junit report - after the build, its number appears in the build history, correctly. However, sometimes, after a jenkins restart, the latest build (262) has disapeared from the build history, so the first one is the previous (261)! Even the artifact published are from the previous build (261). If I go in the workspace I can see files created by the latest build. When I start a new build, the build number is as expected (263). It's like if the build enumeration system skips the latest build. I join the jenkins log in attachment. As you can see the OCHD_Inc_Build_HEAD_05_Non_Reg_Tests_RHES5_64_Atomix_Dual_Channels jobs starts enumerating jobs by #261 while the job #262 has been ignored (the directory .../OCHD_Inc_Build_HEAD_05_Non_Reg_Tests_RHES5_64_Atomix_Dual_Channels/builds/262 exists... However, lastStable and lastSucessful has not been updated. nextBuildNumber is well set to 263). Thanks, G. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13253) Slave connection reset issues since 1.456
Cees Bos created JENKINS-13253:
--
Summary: Slave connection reset issues since 1.456
Key: JENKINS-13253
URL: https://issues.jenkins-ci.org/browse/JENKINS-13253
Project: Jenkins
Issue Type: Bug
Components: core
Environment: 1.456
Reporter: Cees Bos
Priority: Blocker
We upgrade from 1.451 to 1.456 and now we face several issues with connection
reset.
Due to that issue, the jobs are not successful.
On a particular machine we see this very often.
I have captured some stacktraces from the jobs:
{code}
FATAL: hudson.remoting.RequestAbortedException: java.net.SocketException:
Connection reset
hudson.remoting.RequestAbortedException:
hudson.remoting.RequestAbortedException: java.net.SocketException: Connection
reset
at hudson.remoting.Request.call(Request.java:149)
at hudson.remoting.Channel.call(Channel.java:681)
at hudson.Launcher$RemoteLauncher.kill(Launcher.java:821)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:496)
at hudson.model.Run.run(Run.java:1410)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: hudson.remoting.RequestAbortedException: java.net.SocketException:
Connection reset
at hudson.remoting.Request.abort(Request.java:273)
at hudson.remoting.Channel.terminate(Channel.java:732)
at hudson.remoting.Channel$ReaderThread.run(Channel.java:1157)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:185)
at java.io.FilterInputStream.read(FilterInputStream.java:133)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
at
java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2265)
at
java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2558)
at
java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2568)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1314)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
at hudson.remoting.Channel$ReaderThread.run(Channel.java:1127)
{code}
{code}
Archiving artifacts
ERROR: Failed to archive artifacts: allLogs/**/*.*
hudson.util.IOException2: java.io.IOException
at
hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:175)
at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61)
at java.io.FilterInputStream.read(FilterInputStream.java:107)
at hudson.util.HeadBufferingStream.fillSide(HeadBufferingStream.java:83)
at hudson.FilePath$TarCompression$2.extract(FilePath.java:612)
at hudson.FilePath.copyRecursiveTo(FilePath.java:1729)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656)
at hudson.model.Build$RunnerImpl.post2(Build.java:162)
at
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625)
at hudson.model.Run.run(Run.java:1435)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
at hudson.FilePath.copyRecursiveTo(FilePath.java:1736)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678)
at
hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656)
at hudson.model.Build$RunnerImpl.post2(Build.java:162)
at
hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625)
at hudson.model.Run.run(Run.java:1435)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: java.util.concurrent.ExecutionException:
hudson.remoting.RequestAbortedException: java.net.SocketException: Connection
reset
at
[JIRA] (JENKINS-13122) Last modification date of files in a zip are not the original timestamps
[ https://issues.jenkins-ci.org/browse/JENKINS-13122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cees Bos reopened JENKINS-13122: I tested it with build 1.456, but the files in the zip all has the data + time of the moment I downloaded the zip. Last modification date of files in a zip are not the original timestamps Key: JENKINS-13122 URL: https://issues.jenkins-ci.org/browse/JENKINS-13122 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: Cees Bos Assignee: sogabe When do have archiving for a build, then the files on the master have the original timestamps of the file (same as on the slave). But when you download it in a zip with '(all files in zip)' then the last modification date of file is the datetime of that moment, instead of original. We have a job which archives a number of logfiles. Normally you can order it on datetime to get the last logfile, but when you download it in a zip ordering is impossible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13122) Last modification date of files in a zip are not the original timestamps
[ https://issues.jenkins-ci.org/browse/JENKINS-13122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cees Bos closed JENKINS-13122. -- Resolution: Fixed Ok, I overlooked that. I thought it was fixed in 1.456. Apologize. Last modification date of files in a zip are not the original timestamps Key: JENKINS-13122 URL: https://issues.jenkins-ci.org/browse/JENKINS-13122 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: Cees Bos Assignee: sogabe When do have archiving for a build, then the files on the master have the original timestamps of the file (same as on the slave). But when you download it in a zip with '(all files in zip)' then the last modification date of file is the datetime of that moment, instead of original. We have a job which archives a number of logfiles. Normally you can order it on datetime to get the last logfile, but when you download it in a zip ordering is impossible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13231) New Breadcrumb bar covers part of Console output page
Cees Bos created JENKINS-13231: -- Summary: New Breadcrumb bar covers part of Console output page Key: JENKINS-13231 URL: https://issues.jenkins-ci.org/browse/JENKINS-13231 Project: Jenkins Issue Type: Bug Components: core Reporter: Cees Bos Attachments: breadcrumb_consoleoutput.png See attached image !breadcrumb_consoleoutput.png! The top right corner of the consoleoutput page is covered by the breadcrumb. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13122) Last modification date of files in a zip are not the original timestamps
Cees Bos created JENKINS-13122: -- Summary: Last modification date of files in a zip are not the original timestamps Key: JENKINS-13122 URL: https://issues.jenkins-ci.org/browse/JENKINS-13122 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: Cees Bos When do have archiving for a build, then the files on the master have the original timestamps of the file (same as on the slave). But when you download it in a zip with '(all files in zip)' then the last modification date of file is the datetime of that moment, instead of original. We have a job which archives a number of logfiles. Normally you can order it on datetime to get the last logfile, but when you download it in a zip ordering is impossible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-1519) PMD: plugin tries to read files from master in stead of slave
[ https://issues.jenkins-ci.org/browse/JENKINS-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cees Bos closed JENKINS-1519. - Resolution: Fixed This is fixed a long time ago PMD: plugin tries to read files from master in stead of slave - Key: JENKINS-1519 URL: https://issues.jenkins-ci.org/browse/JENKINS-1519 Project: Jenkins Issue Type: Bug Components: pmd Affects Versions: current Environment: Platform: All, OS: All Reporter: Cees Bos I have installed the PMD plugin and use it. (We also have installed the violations plugin and I want to compare them). When I drill down in the report I get the page with packages. There I can drill down top the file overview. From therer I can drill down to the code of the file. There I get: Can't read file /path/to/file.java (No such file or directory) This path is a path which exists on the slave, but my feeling is that it tries to read it on the master. Is this plugin tested in a master/slave configuration of Hudson? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12801) When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
Cees Bos created JENKINS-12801:
--
Summary: When there are 2 PMD warnings on 1 line the Jenkins
report does only report 1
Key: JENKINS-12801
URL: https://issues.jenkins-ci.org/browse/JENKINS-12801
Project: Jenkins
Issue Type: Bug
Components: pmd
Reporter: Cees Bos
Assignee: Ulli Hafner
We have this line of code:
{code:java}
public boolean hasNext()
{
return cursor == EMPTY entity != EMPTY;
}
{code}
PMD xml report has these violations reported:
{code:xml}
violation beginline=216 endline=216 begincolumn=32 endcolumn=46
rule=CompareObjectsWithEquals ruleset=Design Rules
package=com.myapplication.util.collections
class=SingleSet$SingleSetIterator method=hasNext
externalInfoUrl=http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals;
priority=3
Use equals() to compare object references.
/violation
violation beginline=216 endline=216 begincolumn=51 endcolumn=65
rule=CompareObjectsWithEquals ruleset=Design Rules
package=com.myapplication.util.collections
class=SingleSet$SingleSetIterator method=hasNext
externalInfoUrl=http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals;
priority=3
Use equals() to compare object references.
/violation
{code}
Is reports 2 issues on the same line. Other begincolumn and other endcolumn.
In the UI it is only reported once.
And the total number of violations does not match with the actual number of
violations.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
