This is a community project. If you need commercial support with
corresponding SLAs then you might consider obtaining a support contract
from a commercial supplier. I know my employers (CloudBees) are in this
realm and I am aware that there are others.
Otherwise, unless you can find somebody who i
Any idea about how long it should take before I get at least an
acknoledgement on my JIRA?
On Wednesday, May 18, 2016 at 1:26:24 PM UTC-4, Ugo Bellavance wrote:
>
> https://issues.jenkins-ci.org/browse/JENKINS-34919
>
> On Wednesday, May 18, 2016 at 10:45:44 AM UTC-4, Ugo Bellavance wrote:
>>
>>
https://issues.jenkins-ci.org/browse/JENKINS-34919
On Wednesday, May 18, 2016 at 10:45:44 AM UTC-4, Ugo Bellavance wrote:
>
> We only have 1 Jenkins server so I'll create a JIRA,
>
> Thanks a lot for your help :)!
>
> On Wednesday, May 18, 2016 at 10:40:21 AM UTC-4, Stephen Connolly wrote:
>>
>> I
We only have 1 Jenkins server so I'll create a JIRA,
Thanks a lot for your help :)!
On Wednesday, May 18, 2016 at 10:40:21 AM UTC-4, Stephen Connolly wrote:
>
> If you have no slaves and only run builds on the master then we can
> definitively state that JENKINS-34573 is not the root cause. If y
If you have no slaves and only run builds on the master then we can
definitively state that JENKINS-34573 is not the root cause. If you have
slaves (even if idle or unused) then we cannot.
If you have a definitive answer to the above question then you should
probably create a JIRA
On 18 May 2016
Hi Stephen,
We don't use slaves. We only have one master.
Should I create an issue in JIRA for my specific issue?
(is there a reason why you got the conservation out of the group?)
Thanks,
On Wed, May 18, 2016 at 8:56 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> Hard to sa
Hard to say for certain as that could still be references maintained by the
unexported objects that are pending unexport. If you can get your instance
into that state and then have it sit idle for a couple of hours... if it is
JENKINS-34573 then you should see the retained memory reduce as one
refe
Ok, I did analyse the heap dump with Eclipse's Memory Analyzer Tool and
here's what I found:
One instance of "java.util.concurrent.ScheduledThreadPoolExecutor" loaded
by "" occupies 6,801,517,856 (89.16%) bytes. The
instance is referenced by
org.tmatesoft.svn.core.wc.DefaultSVNRepositoryPool @
Jenkins 2.5 has the fix IIUC
On 17 May 2016 at 14:28, Stephen Connolly
wrote:
> It is fixed, but in the latest version of remoting... which is not
> something you can upgrade without either building a custom build of Jenkins
> or upgrading Jenkins.
>
> You could crack open your jenkins.war and r
It is fixed, but in the latest version of remoting... which is not
something you can upgrade without either building a custom build of Jenkins
or upgrading Jenkins.
You could crack open your jenkins.war and replace the remoting.jar with the
fixed version and seal it back up again and see if that f
Thanks, but I can see that this issue is fixed but I don't know how to
update my Jenkins install so that I have the fix. I'm using 1.656.
Ugo
On Tuesday, May 17, 2016 at 8:56:34 AM UTC-4, Stephen Connolly wrote:
>
> I will repeat:
>
> > I am suspecting JENKINS-34213 may be your issue.
>
> On 17
I will repeat:
> I am suspecting JENKINS-34213 may be your issue.
On 17 May 2016 at 13:12, Ugo Bellavance wrote:
>
>
> On Friday, May 13, 2016 at 8:50:56 AM UTC-4, Ugo Bellavance wrote:
>>
>>
>>
>> On Thursday, May 12, 2016 at 2:01:41 PM UTC-4, Raymond Accary wrote:
>>>
>>> Hi,
>>> If it helps,
On Friday, May 13, 2016 at 8:50:56 AM UTC-4, Ugo Bellavance wrote:
>
>
>
> On Thursday, May 12, 2016 at 2:01:41 PM UTC-4, Raymond Accary wrote:
>>
>> Hi,
>> If it helps, you might avoid the crash by installing the monitoring
>> plugin, and triggering garbage collection once the memory is approac
On Thursday, May 12, 2016 at 2:01:41 PM UTC-4, Raymond Accary wrote:
>
> Hi,
> If it helps, you might avoid the crash by installing the monitoring
> plugin, and triggering garbage collection once the memory is approaching
> the maximum allocated heap size. This is a workaround until someone is
Hi,
If it helps, you might avoid the crash by installing the monitoring plugin,
and triggering garbage collection once the memory is approaching the
maximum allocated heap size. This is a workaround until someone is able to
diagnose the root cause. I have an open issue
: https://issues.jenkins-
On Thursday, May 12, 2016 at 10:49:02 AM UTC-4, Ugo Bellavance wrote:
>
>
>
> On Thursday, May 12, 2016 at 4:31:37 AM UTC-4, Stephen Connolly wrote:
>>
>> I am suspecting JENKINS-34213 may be your issue.
>>
>
> I have new information. We installed the monitoring plugin and I started
> using Vis
On Thursday, May 12, 2016 at 4:31:37 AM UTC-4, Stephen Connolly wrote:
>
> I am suspecting JENKINS-34213 may be your issue.
>
I have new information. We installed the monitoring plugin and I started
using VisualVM. I can see that, while I use -Xmx10752m, it only uses a
little less than 8 GB.
I am suspecting JENKINS-34213 may be your issue.
On 11 May 2016 at 18:18, Ugo Bellavance wrote:
>
>
> On Wednesday, May 11, 2016 at 12:32:59 PM UTC-4, John Mellor wrote:
>>
>> Yeah, I’m seeing that too, and I am also running Jenkins 1.656 version.
>> I’m only running about 400 jobs in Jenkins wi
On Wednesday, May 11, 2016 at 12:32:59 PM UTC-4, John Mellor wrote:
>
> Yeah, I’m seeing that too, and I am also running Jenkins 1.656 version.
> I’m only running about 400 jobs in Jenkins with 11 slaves, so it’s
> definitely not the busiest build environment out there. I’ve currently
> bump
Yeah, I’m seeing that too, and I am also running Jenkins 1.656 version. I’m
only running about 400 jobs in Jenkins with 11 slaves, so it’s definitely not
the busiest build environment out there. I’ve currently bumped the heap up to
5GB, and still do not have anywhere near enough to run the bac
20 matches
Mail list logo
