I just see these:
Feb 6, 2013 9:50:10 PM
hudson.plugins.im.IMConnectionProvider$ConnectorRunnable run
INFO: Reconnect failed. Next connection attempt in 16 minutes
Feb 6, 2013 9:51:40 PM hudson.slaves.SlaveComputer tryReconnect
INFO: Attempting to reconnect dmwm-agent-int-old
Feb 6, 2013 10:01:53
I'm also having an intermuitant 100% CPU problem.
I found that the Jenkins Monitoring plugin was a big help in identifiying
the offending threads.
In my case, it is casued by looking at an EMMA code coverage report in the
browser.
-Richard
On Thursday, February 7, 2013 9:47:20 AM UTC-8, An
Hi Oliver,
It doesn't appear to have helped. Hitting the asyncPeople link pegs
the CPU and just stalls. FWIW, I'm on the LTS release and have updated
all the plugins to their latest versions.
-Andrew
On Thu, Feb 7, 2013 at 10:46 AM, Andrew Melo wrote:
> On Thu, Feb 7, 2013 at 4:10 AM, oliver go
On Thu, Feb 7, 2013 at 4:10 AM, oliver gondža wrote:
> On Wed, 06 Feb 2013 21:13:42 +0100, Andrew Melo
> wrote:
>
>> Hey everyone,
>>
>> Sorry for resurrecting that thread, but are there any solutions for
>> this problem? It's basically killing our instance often.
>>
>> best,
>> Andrew
>
>
> Hi,
On Wed, 06 Feb 2013 21:13:42 +0100, Andrew Melo
wrote:
Hey everyone,
Sorry for resurrecting that thread, but are there any solutions for
this problem? It's basically killing our instance often.
best,
Andrew
Hi, subversion-plugin in version 1.45 does not longer have
MailAddressResolver i
Are there any errors/exceptions in Jenkins log files or stdout/stderr?
-- Sami
Andrew Melo kirjoitti 6.2.2013 kello 22.13:
> Hey everyone,
>
> Sorry for resurrecting that thread, but are there any solutions for
> this problem? It's basically killing our instance often.
>
> best,
> Andrew
>
>
Hey everyone,
Sorry for resurrecting that thread, but are there any solutions for
this problem? It's basically killing our instance often.
best,
Andrew
On Wed, Aug 1, 2012 at 11:47 AM, Andrew Melo wrote:
> Oh, wow, I didn't notice, but jenkins has autopopulated a user for
> everyone that ever c
Oh, wow, I didn't notice, but jenkins has autopopulated a user for
everyone that ever committed on the project. There's like 30 people,
~4000 commits, so I could see why that would take a while :)
On Wed, Aug 1, 2012 at 11:42 AM, Andrew Melo wrote:
> On Wed, Aug 1, 2012 at 11:37 AM, Slide wrote:
On Wed, Aug 1, 2012 at 11:37 AM, Slide wrote:
> Can you gist your global config.xml and something from one of your
> jobs as well? Please remember to sanitize it.
We actually keep it stored in SCM. https://github.com/dmwm/jenkins/
And the following is the gist for the job we run each commit (did
Can you gist your global config.xml and something from one of your
jobs as well? Please remember to sanitize it.
On Wed, Aug 1, 2012 at 9:34 AM, Andrew Melo wrote:
> On Wed, Aug 1, 2012 at 11:26 AM, Slide wrote:
>> No, because its only looking for the email address because it wants to
>> send an
On Wed, Aug 1, 2012 at 11:26 AM, Slide wrote:
> No, because its only looking for the email address because it wants to
> send an email to that user.
I don't know who's getting emailed. I don't remember setting it up for
anything, and we actually wrote some scripts that turn jenkins
success/failur
No, because its only looking for the email address because it wants to
send an email to that user.
On Wed, Aug 1, 2012 at 9:24 AM, Andrew Melo wrote:
> On Wed, Aug 1, 2012 at 11:22 AM, Slide wrote:
>> This is a huge issue with the email-ext plugin as well when it does
>> email address resolution
On Wed, Aug 1, 2012 at 11:22 AM, Slide wrote:
> This is a huge issue with the email-ext plugin as well when it does
> email address resolution. Quite a number of people have complained
> about how long it takes. I have yet to come up with a good solution.
> The perforce plugin has a similar issue.
On Wed, Aug 1, 2012 at 11:17 AM, Vojtech Juranek wrote:
> Looks like you it does search for user's email:
> hudson.scm.SubversionMailAddressResolverImpl.findMailAddressFor
> and spends time parsing changelogs:
> hudson.scm.SubversionChangeLogParser.parse
>
> I guess you have quite large instance,
This is a huge issue with the email-ext plugin as well when it does
email address resolution. Quite a number of people have complained
about how long it takes. I have yet to come up with a good solution.
The perforce plugin has a similar issue.
slide
On Wed, Aug 1, 2012 at 9:17 AM, Vojtech Jurane
Looks like you it does search for user's email:
hudson.scm.SubversionMailAddressResolverImpl.findMailAddressFor
and spends time parsing changelogs:
hudson.scm.SubversionChangeLogParser.parse
I guess you have quite large instance, otherwise this operation would be quite
fast.
If you have some job,
On Wed, Aug 1, 2012 at 10:36 AM, Vojtech Juranek wrote:
> On Wednesday 01 August 2012 10:07:15 Andrew Melo wrote:
>> On Wed, Aug 1, 2012 at 9:48 AM, Vojtech Juranek wrote:
>> > quick way how to look what the thread consuming CPU is doing is to do
>> > thread dump (e.g. using jstack $PID) and use
On Wednesday 01 August 2012 10:07:15 Andrew Melo wrote:
> On Wed, Aug 1, 2012 at 9:48 AM, Vojtech Juranek wrote:
> > quick way how to look what the thread consuming CPU is doing is to do
> > thread dump (e.g. using jstack $PID) and use top with threads on (H
> > option) and then look up, see e.g.
On Wed, Aug 1, 2012 at 9:48 AM, Vojtech Juranek wrote:
> quick way how to look what the thread consuming CPU is doing is to do thread
> dump (e.g. using jstack $PID) and use top with threads on (H option) and then
> look up, see e.g.
> http://code.nomad-labs.com/2010/11/18/identifying-which-java-t
quick way how to look what the thread consuming CPU is doing is to do thread
dump (e.g. using jstack $PID) and use top with threads on (H option) and then
look up, see e.g.
http://code.nomad-labs.com/2010/11/18/identifying-which-java-thread-is-
consuming-most-cpu/
On Wednesday 01 August 2012 09:
On Tue, Jul 31, 2012 at 2:54 PM, Les Mikesell wrote:
> On Tue, Jul 31, 2012 at 2:38 PM, Andrew Melo wrote:
>>> But if it happened before June 30th or the system has been rebooted
>>> since, this is not the problem.
>>
>> Well, and it's only when i'm using the web interface (or if background
On Tue, Jul 31, 2012 at 2:38 PM, Andrew Melo wrote:
>>>
>> But if it happened before June 30th or the system has been rebooted
>> since, this is not the problem.
>
> Well, and it's only when i'm using the web interface (or if background
> stuff is happening)
>
It affects the linux futex() system
On Tue, Jul 31, 2012 at 2:36 PM, Les Mikesell wrote:
> On Tue, Jul 31, 2012 at 2:17 PM, Andrew Melo wrote:
>> >>
For some reason, if I watch top on my master while I browse around on
the web interface, the java process stays pegged at 99-100% and it
takes several seconds to render.
On Tue, Jul 31, 2012 at 2:17 PM, Andrew Melo wrote:
> >>
>>> For some reason, if I watch top on my master while I browse around on
>>> the web interface, the java process stays pegged at 99-100% and it
>>> takes several seconds to render. Is there a common reason for that? I
>>> have 2Gb allocated
On Tue, Jul 31, 2012 at 2:16 PM, Les Mikesell wrote:
> On Tue, Jul 31, 2012 at 1:46 PM, Andrew Melo wrote:
>> Hello,
>>
>> For some reason, if I watch top on my master while I browse around on
>> the web interface, the java process stays pegged at 99-100% and it
>> takes several seconds to render
On Tue, Jul 31, 2012 at 1:46 PM, Andrew Melo wrote:
> Hello,
>
> For some reason, if I watch top on my master while I browse around on
> the web interface, the java process stays pegged at 99-100% and it
> takes several seconds to render. Is there a common reason for that? I
> have 2Gb allocated t
26 matches
Mail list logo
