Yes, it looks good. Thanks!
Olivier Lamy wrote:
Hi,
This should be fixed in trunk.
If you have some minutes to test it with database ?
Thanks,
--
Olivier
2008/9/6 Olivier Lamy <[EMAIL PROTECTED]>:
2008/9/5 Peter Janes <[EMAIL PROTECTED]>:
Olivier Lamy wrote:
When you say "After adding a set of projects" : do you stop and
restart continuum with some projects in the queue (build or checkout
queue) ?
At the time the problem first appeared I hadn't restarted the server in a
few months. Since then I've restarted a few times, but I've tried to ensure
that the queue is empty by cancelling any outstanding jobs.
Ah ok it's an old database with probably a lot of buid result and
probably a lot of ScmChangeSet (table SCMRESULT).
I think I understand the trouble here.
To upgrade continuum you have probably interrupt a build when
shutdown/kill tomcat.
If a build is interrupted brutally the endtime for this is 0.
Continuum to report scm changes between two build search all scmresult
between the endtime of the last and the endtime of the "old one" (the
one before), [1]
If this one has a end time of time of 0, this means all scmresult for
your project will go in memory and for an old database this can be
huge !!
Because there is a contains call [2] which use the equals method of
ScmChangeSet [3] which build in memory a lot String (all changed file)
I think we have to reduce the number of ScmResult we build in memory here.
--
Olivier
[1]
http://fisheye6.atlassian.com/browse/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/buildcontroller/DefaultBuildController.java?r=691325#l348
[2]
http://fisheye6.atlassian.com/browse/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/buildcontroller/DefaultBuildController.java?r=691325#l798
[3]
http://fisheye6.atlassian.com/browse/continuum/trunk/continuum-model/src/main/mdo/continuum.xml?r=681492
Are you sure about the rev you are using 691325 ? Can you have a look
at the About Page ?
I was using 662847, then upgraded to 691325 after my second attempt at
adding projects caused the CPU loop.
When I look at the dump, I see :
at
org.apache.maven.continuum.buildcontroller.DefaultBuildController.getOldScmResult(DefaultBuildController.java:776)
And line 776 [1] is a blank line.
Can you try with a 1.2 release candidate :
http://people.apache.org/builds/continuum/1.2/
As I see in the dump you are using tomcat, how do you install the war
? with a Context and docBase pointing to the builded war ?
I have had some issues with this if I didn't clean the directory
$CATALINA_HOME/webapps/continuum
I tried clearing the directory and got the same behaviour. However, the new
stack dump *is* different, pointing to line 798 instead. [2] I'll keep that
in mind when doing future upgrades.
BTW, I will try to reproduce this with changing manually the value in
the database.
Thanks,
--
Olivier
[1]
http://fisheye6.atlassian.com/browse/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/buildcontroller/DefaultBuildController.java?r=691325#l776
Thanks,
Peter J.
[2]
http://fisheye6.atlassian.com/browse/continuum/trunk/continuum-core/src/main/java/org/apache/maven/continuum/buildcontroller/DefaultBuildController.java?r=691325#l798
2008/9/5 Peter Janes <[EMAIL PROTECTED]>:
After having this happen a third time I took a closer look at the
database
and saw that one of the entries in the BUILDRESULT table had an END_TIME
of
0. When I changed that field to a current time and restarted the server
Continuum started to work again.
I was able to reproduce the problem by setting the END_TIME of the last
BUILDRESULT to 0, starting the server, and waiting for that project to be
queued. It was resolved again when I reset END_TIME to its original
value.
I've reported this as http://jira.codehaus.org/browse/CONTINUUM-1871 and
attached the thread dump.
Thanks,
Peter J.
[snip]
--
Sometimes the Universe needs a change of perspective.
--J. Michael Straczynski
--
Sometimes the Universe needs a change of perspective.
--J. Michael Straczynski
