[JIRA] [core] (JENKINS-27607) Incorrect MIME type served for api/json?jsonp
Greg horvath commented on JENKINS-27607 Incorrect MIME type served for api/json?jsonp Any ETA on when this will make its way into a new LTS point build? Kind of less than ideal that the fix for several critical security vulnerabilities breaks a rather substantial piece of functionality. 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] [disk-usage] (JENKINS-23706) Plugin Memory Leak : OutOfMemoryError : PermGen space
Greg horvath commented on JENKINS-23706 Plugin Memory Leak : OutOfMemoryError : PermGen space Are you using the TAP plugin? That thing is a beast; we just figured out that it was the cause of multiple Jenkins instances grinding to a halt over the past few days. 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] [ssh-slaves] (JENKINS-20108) SSH slaves can block for a long time in NativePRNG
Greg horvath commented on JENKINS-20108 SSH slaves can block for a long time in NativePRNG Just ran in to the same issue. Wonder if we can get this moving, as the ticket is almost a year old. 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] [maven2] (JENKINS-755) Default JDK meaning in project options is confusing.
Greg horvath commented on JENKINS-755 Default JDK meaning in project options is confusing. This all seems very silly to me. This ticket has been open for 6.5 years, and all about just providing a way to choose a default option? Come now. If I have multiple things installed, I don't want to have to explicitly specify which one I want for every job. Just give a way to select a default, or decide on a way to select a default via heuristic (i.e. first in the list, alphabetical, numerology, whatever) and tell us what it is. But just fix this, please, because it's unnecessarily confusing. And the ticket is 6.5 years old. 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] [ssh-slaves] (JENKINS-21771) Apparent increase in thread usage for slave nodes
Greg horvath
updated JENKINS-21771
Apparent increase in thread usage for slave nodes
Change By:
Greg horvath
(11/Feb/14 8:07 PM)
Description:
After upgrading to Jenkins v1.549, ssh-slaves v1.6, git plugin v2.0.1, git-client plugin v1.6.2, we began observing many errors and job failures when running builds on our slave nodes. The errors were typically of the form:{code}
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
{code}In general, we saw these errors mainly during two stages of the build process: during SCM step (git checkout), and during transfer of a file specified as a job parameter to the slave node. Some examples of these errors are below; however, it is worth noting that we did observe errors at other phases of the build as well (i.e. was not limited to these two phases).
{code}00:00:45.338 ERROR: Workspace has a .git repository, but it appears to be corrupt.00:00:45.972 FATAL: java.io.IOException: Remote call on bob0024 failed00:00:45.972 hudson.remoting.RemotingSystemException: java.io.IOException: Remote call on bob0024 failed00:00:45.973 at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:183)00:00:45.973 at $Proxy65.hasGitRepo(Unknown Source)00:00:45.973 at org.jenkinsci.plugins.gitclient.RemoteGitImpl.hasGitRepo(RemoteGitImpl.java:250)00:00:45.973 at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:824)00:00:45.973 at hudson.plugins.git.GitSCM.checkout(GitSCM.java:872)00:00:45.973 at org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:118)00:00:45.973 at hudson.model.AbstractProject.checkout(AbstractProject.java:1411)00:00:45.973 at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:651)00:00:45.973 at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)00:00:45.973 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:560)00:00:45.973 at hudson.model.Run.execute(Run.java:1670)00:00:45.973 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)00:00:45.973 at hudson.model.ResourceController.execute(ResourceController.java:88)00:00:45.973 at hudson.model.Executor.run(Executor.java:231)00:00:45.973 Caused by: java.io.IOException: Remote call on bob0024 failed00:00:45.973 at hudson.remoting.Channel.call(Channel.java:731)00:00:45.973 at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:167)00:00:45.973 ... 13 more00:00:45.973 Caused by: java.lang.OutOfMemoryError: unable to create new native thread00:00:45.973 at java.lang.Thread.start0(Native Method)00:00:45.973 at java.lang.Thread.start(Thread.java:597)00:00:45.973 at hudson.remoting.AtmostOneThreadExecutor.execute(AtmostOneThreadExecutor.java:88)00:00:45.973 at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:78)00:00:45.973 at hudson.remoting.JarCacheSupport.resolve(JarCacheSupport.java:59)00:00:45.973 at hudson.remoting.ResourceImageBoth.initiateJarRetrieval(ResourceImageBoth.java:40)00:00:45.973 at hudson.remoting.ResourceImageBoth.resolve(ResourceImageBoth.java:22)00:00:45.973 at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:233)00:00:45.973 at java.lang.ClassLoader.loadClass(ClassLoader.java:307)00:00:45.973 at java.lang.ClassLoader.loadClass(ClassLoader.java:248)00:00:45.973 at hudson.util.StreamTaskListener._error(StreamTaskListener.java:132)00:00:45.973 at hudson.util.StreamTaskListener.error(StreamTaskListener.java:141)00:00:45.973 at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.hasGitRepo(CliGitAPIImpl.java:126)00:00:45.973 at hudson.plugins.git.GitAPI.hasGitRepo(GitAPI.java:186)00:00:45.973 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)00:00:45.973 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)00:00:45.973 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)00:00:45.973 at java.lang.reflect.Method.invoke(Method.java:597)00:00:45.973 at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:299)00:00:45.973 at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:280)00:00:45.973 at h
[JIRA] [ssh-slaves] (JENKINS-21771) Apparent increase in thread usage for slave nodes
Greg horvath created JENKINS-21771 Apparent increase in thread usage for slave nodes Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: ssh-slaves Created: 11/Feb/14 8:02 PM Description: After upgrading to Jenkins v1.549, ssh-slaves v1.6, git plugin v2.0.1, git-client plugin v1.6.2, we began observing many errors and job failures when running builds on our slave nodes. The errors were typically of the form: In general, we saw these errors mainly during two stages of the build process: during SCM step (git checkout), and during transfer of a file specified as a job parameter to the slave node. Some examples of these errors are below; however, it is worth noting that we did observe errors at other phases of the build as well (i.e. was not limited to these two phases). These errors were not dependably reproducible, and were nearly impossible to duplicate in isolation (i.e. could not reproduce when just running jobs on a single slave node). After some time debugging and ruling out some things, we determined that perhaps the user nproc limit (ulimit -u) might be too low, based on the errors that w were seeing and what we were able to rule out after debugging. We increased this limit on our slave nodes and...things went back to normal. None of our build and test jobs changed across the update, meaning that any changes we observed were introduced as a result of the upgrade. My question is then: what has changed recently with slave management that has increased the number of per node threads required? We don't yet have solid watermark data on how high it was actually going, but it was high enough to hit the ceiling for system default (1024). Environment: CentOS 6 Project: Jenkins Labels: slave jenkins performance Priority: Major Reporter: Greg horvath 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] [build-flow] (JENKINS-15999) Flow Jobs Do Not Run Properly When Configured to Run on a Node Other Than Master
Greg horvath commented on JENKINS-15999 Flow Jobs Do Not Run Properly When Configured to Run on a Node Other Than Master What's the resolution here? This bug is now nearly 14 months old, and is still a blocker for us.I'd rather not have to fork this plugin and maintain my own internal version, but if it comes to it that's what I'll have to do, since the response to issues posted here leaves a lot to be desired. Maybe I'll fork it and post as its own new plugin. 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-17392) Unacceptably Slow Load Times for First Access of /me/configure page when using LDAP
Greg horvath resolved JENKINS-17392 as Fixed Unacceptably Slow Load Times for First Access of /me/configure page when using LDAP Fixed by removing CVS and SVN plugins. Change By: Greg horvath (17/Apr/13 10:54 PM) Status: Open Resolved 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/groups/opt_out.
[JIRA] [core] (JENKINS-17392) Unacceptably Slow Load Times for First Access of /me/configure page when using LDAP
Greg horvath commented on JENKINS-17392 Unacceptably Slow Load Times for First Access of /me/configure page when using LDAP On a hunch that the mail resolvers were at issue here, I did some digging through recent tickets and found a few. They suggested disabling the CVS and SVN plugins. I did so, and that fixed it for me. Closing. 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-17392) Unacceptably Slow Load Times for First Access of /me/configure page when using LDAP
Greg horvath commented on JENKINS-17392 Unacceptably Slow Load Times for First Access of /me/configure page when using LDAP Looking at the thread dump, I have a possible clue: at hudson.scm.MailAddressResolverImpl.findMailAddressFor(MailAddressResolverImpl.java:21) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:101) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:532) I have seen a similar trace when investigating hung builds, which I eventually traced to having the "Email committers" field selected on the post-build 'Editable email notification' task. We do not use SVN, and this appears to be trying to grab email addresses from SVN, or something. I also have not found a way to disable the behavior anywhere. 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-17392) Unacceptably Slow Load Times for First Access of /me/configure page when using LDAP
Greg horvath updated JENKINS-17392 Unacceptably Slow Load Times for First Access of /me/configure page when using LDAP Thread dumps captured while attemnpting to load the user configure page for the first time. Change By: Greg horvath (17/Apr/13 6:44 PM) Attachment: ci-dev-dumps.zip 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-17392) Unacceptably Slow Load Times for First Access of /me/configure page when using LDAP
Greg horvath created JENKINS-17392 Unacceptably Slow Load Times for First Access of /me/configure page when using LDAP Issue Type: Bug Assignee: Unassigned Components: core Created: 27/Mar/13 6:47 PM Description: When trying to load a user's configure page (i.e. /me/configure) for the first time, it takes an extremely long time to load. Once the page has been loaded once, however, there is no delay in loading the page. We are using LDAP for user info. We have noticed this behavior before, but it had been tolerable in prior versions. This new degradation represents a regression in behavior. This problem makes Jenkins nearly unusable for new users, and requires an inordinate amount of time and manual intervention to workaround. Environment: CentOS 6 Project: Jenkins Labels: jenkins performance Priority: Critical Reporter: Greg horvath 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-15643) Consistent Out Of Memory Error When Adding 101st Build Node
Greg horvath commented on JENKINS-15643 Consistent Out Of Memory Error When Adding 101st Build Node Increasing max proc fixed this. Going to close out the 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 -- 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-15643) Consistent Out Of Memory Error When Adding 101st Build Node
Greg horvath resolved JENKINS-15643 as Not A Defect Consistent Out Of Memory Error When Adding 101st Build Node Change By: Greg horvath (05/Mar/13 5:05 PM) Status: Open Resolved Resolution: Not A Defect 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-15643) Consistent Out Of Memory Error When Adding 101st Build Node
Greg horvath closed JENKINS-15643 as Not A Defect Consistent Out Of Memory Error When Adding 101st Build Node Change By: Greg horvath (05/Mar/13 5:06 PM) Status: Resolved Closed 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-16989) Add Option to Disable the "Build Now" Link on a per-project Basis
Greg horvath created JENKINS-16989 Add Option to Disable the "Build Now" Link on a per-project Basis Issue Type: New Feature Assignee: Unassigned Components: core Created: 27/Feb/13 10:07 PM Description: Would like to be able to disable/hide the "Build Now" link on a per-job basis for jobs that should be triggered in some other way. Project: Jenkins Labels: jenkins Priority: Major Reporter: Greg horvath 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-15999) Flow Jobs Do Not Run Properly When Configured to Run on a Node Other Than Master
Greg horvath commented on JENKINS-15999 Flow Jobs Do Not Run Properly When Configured to Run on a Node Other Than Master Bump. What's the update? Would love to have 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] (JENKINS-15999) Flow Jobs Do Not Run Properly When Configured to Run on a Node Other Than Master
Greg horvath commented on JENKINS-15999 Flow Jobs Do Not Run Properly When Configured to Run on a Node Other Than Master I should also add that when a flow job locked to an external build node runs, all indications are that the job is running on the remote builder (i.e. console output indicates remote builder). Very confusing. 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-15999) Flow Jobs Do Not Run Properly When Configured to Run on a Node Other Than Master
Greg horvath created JENKINS-15999 Flow Jobs Do Not Run Properly When Configured to Run on a Node Other Than Master Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: build-flow Created: 30/Nov/12 8:25 PM Description: When running a flow job that has been configured to run on an external build node (i.e. anything other than master), it doesn't really run there. I discovered this when I added some steps to my job to copy some build artifacts into the flow job's workspace. The workspace variable was set properly for running on an external build node, but when my post-build publisher ran (specifically, the checkstyle step), it would fail because it couldn't find the files that my job had just copied into the workspace. Additionally, viewing the contents of the workspace via the UI indicated that it was empty. Lastly, I confirmed that the workspace directory on the external build node was in fact empty. After some investigation, I discovered that the files were being copied to the correct directory – the directory that it should have been put in on the external build node – but on the master node! If I lock down the job to run on the master node, it works fine. The build artifacts are exactly where I expect them to be, and the publisher runs successfully. The workaround works for me in the near term, but it's not a workable long term solution. One of my Jenkins instances could have many instances of this job running in parallel, and I would have to significantly increase the number of executors on my master node to support this, which we have observed to cause instability. Environment: CentOS 6, Jenkins 1.486 Project: Jenkins Priority: Major Reporter: Greg horvath 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-15643) Consistent Out Of Memory Error When Adding 101st Build Node
Greg horvath commented on JENKINS-15643 Consistent Out Of Memory Error When Adding 101st Build Node Good suggestion. We did have to bump up our max FD count a while back to get around another issue (too many open files), but the process limit is still set at default. Will give that a try. 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
[JIRA] (JENKINS-15487) External monitoring job exception java.lang.NoSuchMethodError: hudson.model.RunMap.put
Greg horvath commented on JENKINS-15487 External monitoring job exception java.lang.NoSuchMethodError: hudson.model.RunMap.put Looks like we're getting lots of reports that this is not getting fixed in subsequent releases. Right now, a pretty important function is broken for us because of this. Is there any update on when we should expect a fix for this? Even an estimate would be useful (week, month, year, decade, etc). 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-12500) clang scan-build plugin should allow options to be passed directly to scan-build
Greg horvath commented on JENKINS-12500 clang scan-build plugin should allow options to be passed directly to scan-build Ready to close? 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-15575) No Post-Build Actions Are Ever Run
Greg horvath commented on JENKINS-15575 No Post-Build Actions Are Ever Run Bump. 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-15643) Consistent Out Of Memory Error When Adding 101st Build Node
Greg horvath created JENKINS-15643 Consistent Out Of Memory Error When Adding 101st Build Node Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 26/Oct/12 7:20 PM Description: In our Jenkins install, we currently have 98 build nodes attached, with one offline (97 online nodes attached). When adding more nodes, we are consistently seeing an OutOfMemory error when attempting to add the 101st node. This error leaves Jenkins in a strange state – the UI is still responsive, but no jobs can be submitted via the CLI. A restart allows jobs to once again be submitted. We have done a fair amount of cleanup to our plugin installs and decreasing build history, but the behavior is the same. We have not yet done any in-depth memory profiling on the machine to see what happens, but it seems that if it were a real OOM error, the point at which it would occur would be random. We see it consistently occur when adding the 101st build node. This leads me to believe that there is a hard-coded implicit limit on the number of online build nodes which can be attached to a single Jenkins instance at a time. If there is such a limit, it would be good to a) make that explicit and b) remove the limit. If no such limit exists, additional assistance on what could be contributing to these errors would be greatly appreciated. For reference, we are providing java args: -Xmx12G -Xms12G -XX:MaxNewSize=4G -XX:NewSize=4G -XX:MaxPermSize=512M -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:ParallelGCThreads=6 -XX:CMSInitiatingOccupancyFraction=45 Environment: CentOS Project: Jenkins Labels: jenkins exception slave Priority: Critical Reporter: Greg horvath 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-13521) Missing option "E-mail notification" (Post-build Actions)
Greg horvath commented on JENKINS-13521 Missing option "E-mail notification" (Post-build Actions) Good catch. The linked ticket is, I believe, the source of this issue. Need to bump that one. 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-15575) No Post-Build Actions Are Ever Run
Greg horvath created JENKINS-15575 No Post-Build Actions Are Ever Run Issue Type: Bug Assignee: Nicolas De Loof Components: build-flow Created: 18/Oct/12 10:11 PM Description: I can save post build actions, but they are never run. This closed ticket says that it was fixed in the current release, but I don't see that being the case. https://issues.jenkins-ci.org/browse/JENKINS-14411 Please fix so that post-build actions can be run after the flow completes. Environment: Jenkins 1.486 / CentOS Project: Jenkins Priority: Major Reporter: Greg horvath 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
