Hi,
I had to kill Lucene-3.x build #34 [1] and restart the Hudson slave on
lucene.zones.apache.org as the process was stuck since two days. Looks
like the slave got confused due to a communication problem with the
Hudson master, most likely because of an overload on master.
[1] http://hudson.zone
Hi,
On Thu, May 27, 2010 at 1:32 PM, Niklas Gustavsson wrote:
> Should we perhaps increase the maximum PermGen space? I can't find
> that we set it at all today.
I updated the Tomcat startup script to set maxPermSize to 300m (10% of
Xmx). The setting will become active the next time we need to r
On Thu, May 27, 2010 at 1:26 PM, Jukka Zitting wrote:
> Restarted it again, as we were receiving PermGen errors and other
> oddness from Jackrabbit builds.
Should we perhaps increase the maximum PermGen space? I can't find
that we set it at all today.
/niklas
Hi,
On Mon, May 24, 2010 at 7:50 PM, Jukka Zitting wrote:
> Hudson was having trouble, so I restarted it.
Restarted it again, as we were receiving PermGen errors and other
oddness from Jackrabbit builds.
BR,
Jukka Zitting
Hi,
Hudson was having trouble, so I restarted it. Things should be back to
normal soon.
BR,
Jukka Zitting
On Fri, Feb 19, 2010 at 23:33, Jukka Zitting wrote:
> Hi,
>
> I had to restart Hudson again as it stopped responding to HTTP
> requests. I'm not sure if it was the same OOM issue we saw earlier
> today. This time the log shows only simultaneous EOFExceptions from
> vesta and the hadoop slaves 4, 6
On 20/02/10 10:33 AM, Jukka Zitting wrote:
492 Cayenne-trunk
I've now set all the Cayenne projects to retain for 7 days.
Ari
--
-->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Hi,
I had to restart Hudson again as it stopped responding to HTTP
requests. I'm not sure if it was the same OOM issue we saw earlier
today. This time the log shows only simultaneous EOFExceptions from
vesta and the hadoop slaves 4, 6 and 8, and then nothing for an hour
before I forcibly restarted
I think we could limit it by a certain number of days. However, just
taking a look now, and it appears most projects have sane limits -- it
could be the sheer number of projects that causes trouble. disk i/o
on the master is pretty slow, anyway, it seems.
--j.
On Fri, Feb 19, 2010 at 16:59, Juk
Hi,
On Fri, Feb 19, 2010 at 5:37 PM, Justin Mason wrote:
> On Fri, Feb 19, 2010 at 14:42, Jukka Zitting wrote:
>> That's 30mins. Not sure what we can do to speed that up.
>
> Perhaps we should consider archiving old builds at this stage -- we
> have lots, alright.
Agreed. I wouldn't be surprise
On Fri, Feb 19, 2010 at 14:42, Jukka Zitting wrote:
> Hi,
>
> On Fri, Feb 19, 2010 at 2:00 PM, Justin Mason wrote:
>> on the master
>
> Yep, I restarted it as mentioned in the thread about the OOMs.
>
>> it was displaying a "starting" notification for a very long time.
>
> I believe the long
Hi,
On Fri, Feb 19, 2010 at 2:00 PM, Justin Mason wrote:
> on the master
Yep, I restarted it as mentioned in the thread about the OOMs.
> it was displaying a "starting" notification for a very long time.
I believe the long startup time has something to do with the large
number of build job
on the master -- it was displaying a "starting" notification for a
very long time.
--
--j.
13 matches
Mail list logo
