You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefan Bodewig <bo...@apache.org> on 2005/08/25 06:06:05 UTC
[GUMP] Details on JaxMe's test failure
Hi,
this is what the logs says on vmgump, maybe it can give anybody a clue
...
Stefan
Testsuite: org.apache.ws.jaxme.js.junit.VersionTest
Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0.499 sec
------------- Standard Error -----------------
: FINE, getConnection, , Using JDBC driver: org.hsqldb.jdbcDriver
: FINE, getConnection, , Using JDBC url: jdbc:hsqldb:/x1/gump/public/workspace/ws-jaxme/build/js/db/db
: FINE, getConnection, , Using JDBC user: sa
: FINE, getConnection, , Using JDBC driver: org.hsqldb.jdbcDriver
: FINE, getConnection, , Using JDBC url: jdbc:hsqldb:/x1/gump/public/workspace/ws-jaxme/build/js/db/db
: FINE, getConnection, , Using JDBC user: sa
------------- ---------------- ---------------
Testcase: testCreate took 0.467 sec
Caused an ERROR
The database is already in use by another process: org.hsqldb.persist.NIOLockFile@840d0ff[file =/x1/gump/public/workspace/ws-jaxme/build/js/db/db.lck, exists=true, locked=false, valid=false, fl =null]: java.lang.Exception: checkHeartbeat(): lock file [/x1/gump/public/workspace/ws-jaxme/build/js/db/db.lck] is presumably locked by another process.
java.sql.SQLException: The database is already in use by another process: org.hsqldb.persist.NIOLockFile@840d0ff[file =/x1/gump/public/workspace/ws-jaxme/build/js/db/db.lck, exists=true, locked=false, valid=false, fl =null]: java.lang.Exception: checkHeartbeat(): lock file [/x1/gump/public/workspace/ws-jaxme/build/js/db/db.lck] is presumably locked by another process.
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
at org.hsqldb.jdbcDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:512)
at java.sql.DriverManager.getConnection(DriverManager.java:171)
at org.apache.ws.jaxme.js.junit.VersionTest.getConnection(VersionTest.java:178)
at org.apache.ws.jaxme.js.junit.VersionTest.testCreate(VersionTest.java:204)
Testcase: testClone took 0.024 sec
Caused an ERROR
The database is already in use by another process: org.hsqldb.persist.NIOLockFile@840d0ff[file =/x1/gump/public/workspace/ws-jaxme/build/js/db/db.lck, exists=true, locked=false, valid=false, fl =null]: java.lang.Exception: checkHeartbeat(): lock file [/x1/gump/public/workspace/ws-jaxme/build/js/db/db.lck] is presumably locked by another process.
java.sql.SQLException: The database is already in use by another process: org.hsqldb.persist.NIOLockFile@840d0ff[file =/x1/gump/public/workspace/ws-jaxme/build/js/db/db.lck, exists=true, locked=false, valid=false, fl =null]: java.lang.Exception: checkHeartbeat(): lock file [/x1/gump/public/workspace/ws-jaxme/build/js/db/db.lck] is presumably locked by another process.
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.jdbcConnection.<init>(Unknown Source)
at org.hsqldb.jdbcDriver.getConnection(Unknown Source)
at org.hsqldb.jdbcDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:512)
at java.sql.DriverManager.getConnection(DriverManager.java:171)
at org.apache.ws.jaxme.js.junit.VersionTest.getConnection(VersionTest.java:178)
at org.apache.ws.jaxme.js.junit.VersionTest.testClone(VersionTest.java:219)
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP] Details on JaxMe's test failure
Posted by sebb <se...@gmail.com>.
On 26/08/05, Jochen Wiedmann <jo...@gmail.com> wrote:
> On 8/26/05, Stefan Bodewig <bo...@apache.org> wrote:
>
> > Doesn't look as if it worked, aren't we checking out the correct code?
If it's not obvious that the correct script is being used, you could
add a "Revision" property to each of the XML files involved in the
build, and then display them all at the start of the test output.
For an example of how to do this, see the jakarta-jmeter builds.
Can be very useful when you are making changes to the descriptors and
want to know which one has been picked up for the Gump run.
HTH
S.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP] Details on JaxMe's test failure
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 26 Aug 2005, Jochen Wiedmann <jo...@gmail.com>
wrote:
> At line 171 in ant/js.cml, I find the following lines:
>
> <tests>
> <fileset dir="${src.js}">
> <include
> name="org/apache/ws/jaxme/js/junit/**/*Test.java"/>
> <include
> name="org/apache/ws/jaxme/sqls/junit/**/*Test.java"/>
> <exclude
> name="org/apache/ws/jaxme/js/junit/VersionTest.java"/>
> </fileset>
> </tests>
>
> In other words, the failing unit test is explicitly excluded.
Not in Gump's working copy. Just to be sure, CVS and ws-jaxme module
are correct, yes?
> Is it possible for me as a basic committer to inspect the directory,
> where the failed build occurs?
No, not that easily. I just did a "cvs up" and the directory is up to
date.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP] Details on JaxMe's test failure
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 8/26/05, Stefan Bodewig <bo...@apache.org> wrote:
> Doesn't look as if it worked, aren't we checking out the correct code?
From
http://vmgump.apache.org/gump/public/ws-jaxme/ws-jaxme/gump_work/build_ws-jaxme_ws-jaxme.html
I quote the following:
/x1/gump/public/workspace/ws-jaxme/ant/js.xml:171: The following error
occurred while executing this line:
/x1/gump/public/workspace/ws-jaxme/ant/macros.xml:81: Test
org.apache.ws.jaxme.js.junit.VersionTest failed
At line 171 in ant/js.cml, I find the following lines:
<tests>
<fileset dir="${src.js}">
<include name="org/apache/ws/jaxme/js/junit/**/*Test.java"/>
<include
name="org/apache/ws/jaxme/sqls/junit/**/*Test.java"/>
<exclude
name="org/apache/ws/jaxme/js/junit/VersionTest.java"/>
</fileset>
</tests>
In other words, the failing unit test is explicitly excluded.
Sorry, but I am lost here.
Is it possible for me as a basic committer to inspect the directory,
where the failed build occurs?
Thanks,
Jochen
> > In the medium to long term, I have a more important question: Why is
> > it, that we don't receive these nag mails?
>
> Never?
Definitely not within the last week. Your mail was the first one that
we received.
> The regexp elements are left-overs from the "old" Gump, maybe they are
> confusing the cureent incarnation.
Can you name a sample project with a better descriptor?
Regards,
Jochen
--
Having experienced 7 years of labour/green government, I now know the
reason, why a conservative government is good for the economy: The
economy's unable to imagine anything else ...
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: [GUMP] Details on JaxMe's test failure
Posted by Jochen Wiedmann <jo...@gmail.com>.
On 8/26/05, Stefan Bodewig <bo...@apache.org> wrote:
> Doesn't look as if it worked, aren't we checking out the correct code?
From
http://vmgump.apache.org/gump/public/ws-jaxme/ws-jaxme/gump_work/build_ws-jaxme_ws-jaxme.html
I quote the following:
/x1/gump/public/workspace/ws-jaxme/ant/js.xml:171: The following error
occurred while executing this line:
/x1/gump/public/workspace/ws-jaxme/ant/macros.xml:81: Test
org.apache.ws.jaxme.js.junit.VersionTest failed
At line 171 in ant/js.cml, I find the following lines:
<tests>
<fileset dir="${src.js}">
<include name="org/apache/ws/jaxme/js/junit/**/*Test.java"/>
<include
name="org/apache/ws/jaxme/sqls/junit/**/*Test.java"/>
<exclude
name="org/apache/ws/jaxme/js/junit/VersionTest.java"/>
</fileset>
</tests>
In other words, the failing unit test is explicitly excluded.
Sorry, but I am lost here.
Is it possible for me as a basic committer to inspect the directory,
where the failed build occurs?
Thanks,
Jochen
> > In the medium to long term, I have a more important question: Why is
> > it, that we don't receive these nag mails?
>
> Never?
Definitely not within the last week. Your mail was the first one that
we received.
> The regexp elements are left-overs from the "old" Gump, maybe they are
> confusing the cureent incarnation.
Can you name a sample project with a better descriptor?
Regards,
Jochen
--
Having experienced 7 years of labour/green government, I now know the
reason, why a conservative government is good for the economy: The
economy's unable to imagine anything else ...
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP] Details on JaxMe's test failure
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 25 Aug 2005, Jochen Wiedmann <jo...@gmail.com>
wrote:
> I have disabled the failing test in the trunk.
Doesn't look as if it worked, aren't we checking out the correct code?
> In the medium to long term, I have a more important question: Why is
> it, that we don't receive these nag mails?
Never?
Only one Gump run per day - the one starting at midnight on vmgump,
i.e. 9am our time - sends nag mails and the next to last midnight run
was broken because I managed to use a bad repository reference for
xml-commons.
> The gump descriptor contains the email address
> jaxme-dev@ws.apache.org, which should be quite right.
The regexp elements are left-overs from the "old" Gump, maybe they are
confusing the cureent incarnation.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP] Details on JaxMe's test failure
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 25 Aug 2005, Jochen Wiedmann <jo...@gmail.com>
wrote:
> I have disabled the failing test in the trunk.
Doesn't look as if it worked, aren't we checking out the correct code?
> In the medium to long term, I have a more important question: Why is
> it, that we don't receive these nag mails?
Never?
Only one Gump run per day - the one starting at midnight on vmgump,
i.e. 9am our time - sends nag mails and the next to last midnight run
was broken because I managed to use a bad repository reference for
xml-commons.
> The gump descriptor contains the email address
> jaxme-dev@ws.apache.org, which should be quite right.
The regexp elements are left-overs from the "old" Gump, maybe they are
confusing the cureent incarnation.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: [GUMP] Details on JaxMe's test failure
Posted by Jochen Wiedmann <jo...@gmail.com>.
Stefan,
thanks for the hint. I have disabled the failing test in the trunk. The
problem is generally known and no actual failure, but a question of
locking in hsqldb. The problem should be fixed in the short term.
In the medium to long term, I have a more important question: Why is it,
that we don't receive these nag mails? The gump descriptor contains the
email address jaxme-dev@ws.apache.org, which should be quite right. The
sender address (dims@yahoo.com) should also be allowed for postings
(see, for example
http://www.google.de/search?q=%2Bsite%3Amail-archives.apache.org%2Fmod_mbox%2Fws-jaxme-dev+%22dims%40yahoo.com%22
I have observed that failure of nagging mails more than once.
Thanks,
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [GUMP] Details on JaxMe's test failure
Posted by Jochen Wiedmann <jo...@gmail.com>.
Stefan,
thanks for the hint. I have disabled the failing test in the trunk. The
problem is generally known and no actual failure, but a question of
locking in hsqldb. The problem should be fixed in the short term.
In the medium to long term, I have a more important question: Why is it,
that we don't receive these nag mails? The gump descriptor contains the
email address jaxme-dev@ws.apache.org, which should be quite right. The
sender address (dims@yahoo.com) should also be allowed for postings
(see, for example
http://www.google.de/search?q=%2Bsite%3Amail-archives.apache.org%2Fmod_mbox%2Fws-jaxme-dev+%22dims%40yahoo.com%22
I have observed that failure of nagging mails more than once.
Thanks,
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org