www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <krist...@apache.org>
Subject Re: Use of Lucene Zones
Date Tue, 23 Feb 2010 21:35:01 GMT
Den 23.02.2010 18:50, skrev Grant Ingersoll:
> 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?

Hi Grant,

Not really, but I have moved the Derby jobs off the Lucene zone (see 
comment on INFRA-2502). I got into the Hudson-game a bit late, so I must 
have missed the discussions you refer to (and I haven't read the archives).

A while back I asked on the builds-list (see "Hudson Derby jobs", 
2009-11-24) if the zones machine could handle another zone running 
Hudson jobs, but I don't think I got any feedback. Derby isn't using its 
zone for anything, so I can ask the PMC again if we can donate the zone 
to Hudson. Before doing that I'd like to get a +1 from infra regarding 
the hardware utilization situation.

Sorry for doing something I wasn't supposed to do, hope it didn't cause 
too much trouble.


[1] https://issues.apache.org/jira/browse/INFRA-2502

> -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.Channel@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)
>> 	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

View raw message