You are viewing a plain text version of this content. The canonical link for it is here.
Posted to builds@apache.org by Grant Ingersoll <gs...@apache.org> on 2010/02/23 18:50:22 UTC
Use of Lucene Zones Re: Hudson build failed on lucene.zones.apache.org with OOME
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.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) 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
>
>
>
Re: Use of Lucene Zones Re: Hudson build failed on
lucene.zones.apache.org with OOME
Posted by Kristian Waagan <kr...@apache.org>.
On 24.02.10 12:03, Justin Mason wrote:
> 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?
Hi Justin,
Yes I did, after Grant brought up this issue. I'm the one who created
the jobs and put them on the Lucene zone in the first place.
Derby-trunk, Derby-branch-10.5, and Derby-docs used to run on the Lucene
zone. The first two polling svn hourly (run time < 10 min), the last one
polling svn twice a week (run time ~45 min).
The two last jobs (Derby-trunk_suites.All and Derby-trunk_clover) are
more experimental jobs. The former runs the Derby test suite (takes 3
hours+, grabs lock), whereas the latter was supposed to publish Clover
reports. However, testing on a non-ASF machine showed that generating
the HTML report took more than 26 hours, so this job won't be running in
Hudson... I'm also afraid that the ASF servers won't be too happy
serving 10 MB+ HTML files (report dir ends up at 2.6 GB).
I'm still investigating if I can configure Clover to do less work and
generate a smaller report a lot faster (i.e. disable per test coverage
and cutting down the number of instrumented classes, this task is on the
back-burner for now).
--
Kristian
>
>
>
> On Tue, Feb 23, 2010 at 17:50, Grant Ingersoll<gs...@apache.org> 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.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) 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
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: Use of Lucene Zones Re: Hudson build failed on
lucene.zones.apache.org with OOME
Posted by Justin Mason <jm...@jmason.org>.
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 <gs...@apache.org> 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.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) 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.
Re: Use of Lucene Zones
Posted by Grant Ingersoll <gs...@apache.org>.
On Feb 23, 2010, at 4:35 PM, Kristian Waagan wrote:
> 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.
No, definitely not a big deal. Bringing it up more for your sanity than anything else, as the Lucene PMC, of course, reserves the right to change our Zone (not that we have) so that something you relied on may not be there in the future.
-Grant
Re: Use of Lucene Zones
Posted by Kristian Waagan <kr...@apache.org>.
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.
Regards,
--
Kristian
[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) 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
>>
>>
>>
>
>