hi Grant -- looking at the Derby configuration pages, they all seem to be tied to a node or pair of nodes:
http://hudson.zones.apache.org/hudson/view/Derby/job/Derby-branch-10.5/configure Ubuntu (minerva, vesta) http://hudson.zones.apache.org/hudson/view/Derby/job/Derby-docs/configure Ubuntu (minerva, vesta) http://hudson.zones.apache.org/hudson/view/Derby/job/Derby-trunk/configure Ubuntu (minerva, vesta) http://hudson.zones.apache.org/hudson/view/Derby/job/Derby-trunk_suites.All/configure minerva only however I can see that Derby-trunk build in http://hudson.zones.apache.org/hudson/computer/lucene.zones.apache.org%20%28Solaris%2010%29/builds 15 hours ago. Did someone change the Derby-trunk job since then? On Tue, Feb 23, 2010 at 17:50, Grant Ingersoll <[email protected]> wrote: > I'm a bit confused why Derby is using the Lucene Zone to begin with. Doesn't > Derby have it's own Zone? I don't necessarily have a problem with it, but it > would be nice if the Lucene PMC was asked before our resources are utilized. > I'm sure it was just assumed b/c the Lucene Zone shows up in Hudson, but my > understanding from earlier discussions was that it was done out of > convenience for Lucene (b/c that's where Hudson was first installed anyway) > and that other Zones would be setup if projects wanted to provide their own > resources to Hudson and that other build machines were provisioned to support > the majority of projects > > Anyone else have any insight? > > -Grant > > On Feb 19, 2010, at 6:59 AM, Kristian Waagan wrote: > >> Hi, >> >> I don't know if this error requires action to be taken by an administrator, >> but the last Derby-trunk build failed with the following stack trace: >> >> [Kristian Waagan] DERBY-4400: Document the process of producing Maven 2 >> artifacts for Derby. >> >> Minor formatting changes. >> Fixed some typos. >> >> ------------------------------------------ >> Failed to access build log >> >> hudson.util.IOException2: remote file operation failed: >> /export/home/hudson/hudson-slave/workspace/Derby-trunk >> athudson.remoting.chan...@84bdd1:lucene.zones.apache.org (Solaris 10) >> at hudson.FilePath.act(FilePath.java:690) >> at hudson.FilePath.act(FilePath.java:676) >> at hudson.FilePath.toURI(FilePath.java:731) >> at hudson.tasks.MailSender.createFailureMail(MailSender.java:256) >> at hudson.tasks.MailSender.getMail(MailSender.java:133) >> at hudson.tasks.MailSender.execute(MailSender.java:81) >> at hudson.tasks.Mailer.perform(Mailer.java:99) >> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) >> at >> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:582) >> at >> hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563) >> at >> hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:550) >> at hudson.model.Build$RunnerImpl.post2(Build.java:152) >> at >> hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:528) >> at hudson.model.Run.run(Run.java:1221) >> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) >> at hudson.model.ResourceController.execute(ResourceController.java:88) >> at hudson.model.Executor.run(Executor.java:122) >> Caused by: java.io.IOException: Remote call on lucene.zones.apache.org >> (Solaris 10) failed >> at hudson.remoting.Channel.call(Channel.java:560) >> at hudson.FilePath.act(FilePath.java:683) >> ... 16 more >> Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded >> >> >> Am I correct in assuming this is the Hudson slave process, and not the >> process building the code? (I further assume these are two separate >> processes) >> The changes for this build were only text changes to a README... >> >> I expect another build to be triggered later today, so we'll see if the >> problem goes away or not. >> >> >> Regards, >> -- >> Kristian >> >> >> > > > -- --j.
