8:53 a.m.
The run last night failed because the server was
shutdown before the test finished, see around 03:17:26
http://hudson.jboss.org/hudson/job/JBoss-AS-5.0.x-TestSuite-sun15/849/art...
It's currently failing for me, because of an NPE,
which looks related to Alex's change:
Caused by: java.lang.NullPointerException
at
org.jboss.resource.metadata.mcf.ManagedConnectionFactoryDeploymentMetaData.setTrackConnectionByTransaction(ManagedConnectionFactoryDeploymentMetaData.java:5
29)
at
org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at
org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at
org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143)
at
org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.setValue(AbstractInstanceClassFactory.java:303)
at
org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.setValue(AbstractInstanceClassFactory.java:256)
at
org.jboss.managed.plugins.WritethroughManagedPropertyImpl.setValue(WritethroughManagedPropertyImpl.java:109)
at
org.jboss.resource.deployers.management.DsDataSourceTemplate.writeTemplate(DsDataSourceTemplate.java:154)
at
org.jboss.resource.deployers.management.DsDataSourceTemplate.applyTemplate(DsDataSourceTemplate.java:70)
at
org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:673)
-------- Forwarded Message --------
From: Ales Justin <ales.justin(a)gmail.com>
To: Dimitris Andreadis <dandread(a)redhat.com>
Cc: Adrian Brock <abrock(a)redhat.com>, Scott M Stark <sstark(a)redhat.com>,
Bruno Georges <bgeorges(a)redhat.com>
Subject: Re: vacation
Date: Tue, 26 Aug 2008 15:26:23 +0200
They work for me locally, so I don't see how I can look for what's wrong
test:
[delete] Deleting: C:\DOCUME~1\Ales\LOCALS~1\Temp\test.log
[junit] Running org.jboss.test.profileservice.test.DeployUnitTestCase
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 23,953 sec
[junit] Running
org.jboss.test.profileservice.test.JmsDestinationUnitTestCase
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 8,422 sec
[junit] Running
org.jboss.test.profileservice.test.ProfileServiceUnitTestCase
[junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed: 11,875 sec
BUILD SUCCESSFUL
The cause of this failures below is also weird.
Since it states there is testEjb3xDeployment failure
vfszip:/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.CR2/server/profileservice/deploy/testEjb3xDeployment.jar
-> java.util.zip.ZipException: error in opening zip file
But I don't see this test failing among failures.
So, I'll have to leave this one to Scott.
Who probably has more equivalent env to Hudson than me.
Or if Mladen takes his tax-hidden Ferrari for a ride,
bringing me new Linux based laptop, to mock the tests. :-)
Dimitris Andreadis wrote:
Ales, can you take a look at the profileservice tests before you go?
They keep failing and make up 50% of the current failures:
https://jira.jboss.org/jira/browse/JBAS-5625
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
Ales Justin wrote:
> I'll be finally taking some summer vacation. :-)
>
> From this Wednesday 27 Aug till Friday 5 Sept I'll be chilling out
> at Croatia's Adriatic coast.
> Laptop stays at home - 1st time after 2 years - but I'll try to write
> an article about MC/AS5 - targeting demos I started a few weeks ago.
>
> When is JBoss5_CR2 planned?
> If during my absence, then someone else, presumably Adrian,
> needs to do MCs CR1 releases.
>
> I see there are still some JBMICROCONT issues,
> which I'll fix tomorrow.
> And I'll also do a bit of JIRA house-cleaning,
> after the express releases I did to help/fix various TCK issues.
>
> I can still be reached on my Gmail (ales.justin(a)gmail.com)
> as I expect iPhone to work. :-)
>
> Cheers,
> Ales
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
3:11 p.m.
This is irrelevant error,
we should look what's the real cause before.
Since I doubt server shutdown always in the last few runs -
when the failures occurred.
Alex, what's the proper fix for NPE, this?
@Deprecated
public void setTrackConnectionByTransaction(Boolean
trackConnectionByTransaction)
{
if (trackConnectionByTransaction == null)
return;
if(getLocalTransactions() && !trackConnectionByTransaction)
throw new IllegalStateException("In case of local transactions
track-connection-by-tx must always be true");
setInterleaving(!trackConnectionByTransaction);
}
The run last night failed because the server was
shutdown before the test finished, see around 03:17:26
http://hudson.jboss.org/hudson/job/JBoss-AS-5.0.x-TestSuite-sun15/849/art...
It's currently failing for me, because of an NPE,
which looks related to Alex's change:
Caused by: java.lang.NullPointerException
at
org.jboss.resource.metadata.mcf.ManagedConnectionFactoryDeploymentMetaData.setTrackConnectionByTransaction(ManagedConnectionFactoryDeploymentMetaData.java:5
29)
at
org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
at
org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
at
org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143)
at
org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.setValue(AbstractInstanceClassFactory.java:303)
at
org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.setValue(AbstractInstanceClassFactory.java:256)
at
org.jboss.managed.plugins.WritethroughManagedPropertyImpl.setValue(WritethroughManagedPropertyImpl.java:109)
at
org.jboss.resource.deployers.management.DsDataSourceTemplate.writeTemplate(DsDataSourceTemplate.java:154)
at
org.jboss.resource.deployers.management.DsDataSourceTemplate.applyTemplate(DsDataSourceTemplate.java:70)
at
org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:673)
-------- Forwarded Message --------
They work for me locally, so I don't see how I can look for what's wrong
test:
[delete] Deleting: C:\DOCUME~1\Ales\LOCALS~1\Temp\test.log
[junit] Running org.jboss.test.profileservice.test.DeployUnitTestCase
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 23,953 sec
[junit] Running
org.jboss.test.profileservice.test.JmsDestinationUnitTestCase
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 8,422 sec
[junit] Running
org.jboss.test.profileservice.test.ProfileServiceUnitTestCase
[junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed: 11,875 sec
BUILD SUCCESSFUL
The cause of this failures below is also weird.
Since it states there is testEjb3xDeployment failure
vfszip:/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.CR2/server/profileservice/deploy/testEjb3xDeployment.jar
-> java.util.zip.ZipException: error in opening zip file
But I don't see this test failing among failures.
5:33 p.m.
Sorry for the regression.
It seems to me null would be an invalid argument. The template should
not pass in null value. I'll look into this.
Ales Justin wrote:
This is irrelevant error,
we should look what's the real cause before.
Since I doubt server shutdown always in the last few runs -
when the failures occurred.
Alex, what's the proper fix for NPE, this?
@Deprecated
public void setTrackConnectionByTransaction(Boolean
trackConnectionByTransaction)
{
if (trackConnectionByTransaction == null)
return;
if(getLocalTransactions() && !trackConnectionByTransaction)
throw new IllegalStateException("In case of local transactions
track-connection-by-tx must always be true");
setInterleaving(!trackConnectionByTransaction);
}
> The run last night failed because the server was
> shutdown before the test finished, see around 03:17:26
>
>
http://hudson.jboss.org/hudson/job/JBoss-AS-5.0.x-TestSuite-sun15/849/art...
>
>
> It's currently failing for me, because of an NPE,
> which looks related to Alex's change:
>
> Caused by: java.lang.NullPointerException
> at
>
org.jboss.resource.metadata.mcf.ManagedConnectionFactoryDeploymentMetaData.setTrackConnectionByTransaction(ManagedConnectionFactoryDeploymentMetaData.java:5
>
> 29)
> at
>
org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59)
>
> at
>
org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
>
> at
> org.jboss.beans.info.plugins.DefaultPropertyInfo.set(DefaultPropertyInfo.java:143)
>
> at
>
org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.setValue(AbstractInstanceClassFactory.java:303)
>
> at
>
org.jboss.managed.plugins.factory.AbstractInstanceClassFactory.setValue(AbstractInstanceClassFactory.java:256)
>
> at
>
org.jboss.managed.plugins.WritethroughManagedPropertyImpl.setValue(WritethroughManagedPropertyImpl.java:109)
>
> at
>
org.jboss.resource.deployers.management.DsDataSourceTemplate.writeTemplate(DsDataSourceTemplate.java:154)
>
> at
>
org.jboss.resource.deployers.management.DsDataSourceTemplate.applyTemplate(DsDataSourceTemplate.java:70)
>
> at
>
org.jboss.profileservice.management.ManagementViewImpl.applyTemplate(ManagementViewImpl.java:673)
>
>
>
> -------- Forwarded Message --------
>
> They work for me locally, so I don't see how I can look for what's wrong
>
> test:
> [delete] Deleting: C:\DOCUME~1\Ales\LOCALS~1\Temp\test.log
> [junit] Running
> org.jboss.test.profileservice.test.DeployUnitTestCase
> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed:
> 23,953 sec
> [junit] Running
> org.jboss.test.profileservice.test.JmsDestinationUnitTestCase
> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 8,422
> sec
> [junit] Running
> org.jboss.test.profileservice.test.ProfileServiceUnitTestCase
> [junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed:
> 11,875 sec
>
> BUILD SUCCESSFUL
>
> The cause of this failures below is also weird.
> Since it states there is testEjb3xDeployment failure
>
>
vfszip:/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-sun15/trunk/build/output/jboss-5.0.0.CR2/server/profileservice/deploy/testEjb3xDeployment.jar
> -> java.util.zip.ZipException: error in opening zip file
>
> But I don't see this test failing among failures.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
1:38 p.m.
Do we know why the profileservice tests are so vulnerable to breakage:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
Running them one by one locally they pass for me. Running them a second time some failures
show up.
Are the tested modules uploaded to the server deploy dir (because I'm seeing
references to
them in the server.log), or are they stored in memory only?
If they are dropped momentarily in /deploy could the HDScanner accidentally pick them up?
Alexey Loubyansky wrote:
Sorry for the regression.
It seems to me null would be an invalid argument. The template should
not pass in null value. I'll look into this.
...
1:53 p.m.
They are uploaded. They should be deleted though on undeployment.
Dimitris Andreadis wrote:
Do we know why the profileservice tests are so vulnerable to
breakage:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
Running them one by one locally they pass for me. Running them a
second time some failures show up.
Are the tested modules uploaded to the server deploy dir (because I'm
seeing references to them in the server.log), or are they stored in
memory only?
If they are dropped momentarily in /deploy could the HDScanner
accidentally pick them up?
Alexey Loubyansky wrote:
> Sorry for the regression.
>
> It seems to me null would be an invalid argument. The template should
> not pass in null value. I'll look into this.
...
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
4:43 a.m.
Shouldn't we use a different upload dir in data/ or tmp/ to avoid HDScanner seeing
those
deployments?
Scott Stark wrote:
They are uploaded. They should be deleted though on undeployment.
Dimitris Andreadis wrote:
> Do we know why the profileservice tests are so vulnerable to breakage:
>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
>
>
> Running them one by one locally they pass for me. Running them a
> second time some failures show up.
>
> Are the tested modules uploaded to the server deploy dir (because I'm
> seeing references to them in the server.log), or are they stored in
> memory only?
>
> If they are dropped momentarily in /deploy could the HDScanner
> accidentally pick them up?
>
> Alexey Loubyansky wrote:
>> Sorry for the regression.
>>
>> It seems to me null would be an invalid argument. The template should
>> not pass in null value. I'll look into this.
> ...
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
12:43 a.m.
It should not matter because the scanner asks the profile for the
new/changed deployments. It no longer looks directly to the deploy
directory. On OSX the profile service tests are all passing. I'm
updating a fedora box with the current workspace to see its behavior.
Dimitris Andreadis wrote:
Shouldn't we use a different upload dir in data/ or tmp/ to avoid
HDScanner seeing those deployments?
Scott Stark wrote:
> They are uploaded. They should be deleted though on undeployment.
8:11 p.m.
I don't see this in the test runs, and the only box I have reproduced a
failure on is due to an inability of the client to reuse the 4446 port,
and so the client remoting layer fails to startup its streaming port.
Its not even getting to the point of trying a deployment.
I'm now looking into why the current runs are failing to shutdown:
tests-report:
[tar] Building tar:
/Users/svn/JBossHead/jboss-head/testsuite/output/2008-08-31.21-39.tgz
BUILD FAILED
/Users/svn/JBossHead/jboss-head/testsuite/build.xml:969: Some servers
failed to shutdown cleanly.
Total time: 179 minutes 36 seconds
[589][valkyrie: testsuite]$
I have reproduced this, but the server is in fact shutting down. The
last servers run are the cluster-profilesvc-0/1 configs, and their logs
show clean shutdowns. I guess we need more debug output from the server
task as to what it thinks is not shutting down.
Scott Stark wrote:
It should not matter because the scanner asks the profile for the
new/changed deployments. It no longer looks directly to the deploy
directory. On OSX the profile service tests are all passing. I'm
updating a fedora box with the current workspace to see its behavior.
Dimitris Andreadis wrote:
> Shouldn't we use a different upload dir in data/ or tmp/ to avoid
> HDScanner seeing those deployments?
>
> Scott Stark wrote:
>> They are uploaded. They should be deleted though on undeployment.
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
6:42 a.m.
Scott Stark wrote:
I don't see this in the test runs, and the only box I have
reproduced a
failure on is due to an inability of the client to reuse the 4446 port,
and so the client remoting layer fails to startup its streaming port.
Its not even getting to the point of trying a deployment.
I'm now looking into why the current runs are failing to shutdown:
tests-report:
[tar] Building tar:
/Users/svn/JBossHead/jboss-head/testsuite/output/2008-08-31.21-39.tgz
BUILD FAILED
/Users/svn/JBossHead/jboss-head/testsuite/build.xml:969: Some servers
failed to shutdown cleanly.
Total time: 179 minutes 36 seconds
[589][valkyrie: testsuite]$
I have reproduced this, but the server is in fact shutting down. The
last servers run are the cluster-profilesvc-0/1 configs, and their logs
show clean shutdowns. I guess we need more debug output from the server
task as to what it thinks is not shutting down.
Scott, the server shutdown problem must be related to the ant 1.7.1 upgrade:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
2:33 p.m.
Dimitris Andreadis wrote:
Scott Stark wrote:
> I don't see this in the test runs, and the only box I have reproduced
> a failure on is due to an inability of the client to reuse the 4446
> port, and so the client remoting layer fails to startup its streaming
> port. Its not even getting to the point of trying a deployment.
>
> I'm now looking into why the current runs are failing to shutdown:
>
> tests-report:
> [tar] Building tar:
> /Users/svn/JBossHead/jboss-head/testsuite/output/2008-08-31.21-39.tgz
>
> BUILD FAILED
> /Users/svn/JBossHead/jboss-head/testsuite/build.xml:969: Some servers
> failed to shutdown cleanly.
>
> Total time: 179 minutes 36 seconds
> [589][valkyrie: testsuite]$
>
> I have reproduced this, but the server is in fact shutting down. The
> last servers run are the cluster-profilesvc-0/1 configs, and their
> logs show clean shutdowns. I guess we need more debug output from the
> server task as to what it thinks is not shutting down.
Scott, the server shutdown problem must be related to the ant 1.7.1
upgrade:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
I created a jira for this annoying issue:
https://jira.jboss.org/jira/browse/JBAS-5918
I've configured hudson to keep some more logs but I don't understand why
testsuite/output/tests.log gets overwritten with the following:
BUILD FAILED
/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-jrockit15/trunk/testsuite/build.xml:968:
Some servers failed to shutdown cleanly.
at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:142)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
at org.apache.tools.ant.Main.runBuild(Main.java:758)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
In my local run this file contains the test run output (i.e. what the console would show,
from
<record name="output/tests.log" append="no"
action="start" loglevel="info"/>
to
<antcall target="tests-report"/>
<record name="output/tests.log" action="stop"/>
For some reason the following overwrites the file
<condition property="servers.shutdown.failed">
<and>
<not><isset
property="servers.shutdown.nocheck"/></not>
<isfileselected file="output/tests.log">
<or>
<contains text="Unable to shutdown server properly"/>
<not><contains
text="[server:stop]"/></not>
</or>
</isfileselected>
</and>
</condition>
<fail message="Some servers failed to shutdown cleanly."
if="servers.shutdown.failed"/>
3:57 p.m.
I'm going to look into our StopServerTask. I see jboss-test is setup to
compile against ant 1.7.0 so I'm also trying that to see if there is any
difference in behavior.
Dimitris Andreadis wrote:
Dimitris Andreadis wrote:
> Scott Stark wrote:
>> I don't see this in the test runs, and the only box I have
>> reproduced a failure on is due to an inability of the client to
>> reuse the 4446 port, and so the client remoting layer fails to
>> startup its streaming port. Its not even getting to the point of
>> trying a deployment.
>>
>> I'm now looking into why the current runs are failing to shutdown:
>>
>> tests-report:
>> [tar] Building tar:
>> /Users/svn/JBossHead/jboss-head/testsuite/output/2008-08-31.21-39.tgz
>>
>> BUILD FAILED
>> /Users/svn/JBossHead/jboss-head/testsuite/build.xml:969: Some
>> servers failed to shutdown cleanly.
>>
>> Total time: 179 minutes 36 seconds
>> [589][valkyrie: testsuite]$
>>
>> I have reproduced this, but the server is in fact shutting down. The
>> last servers run are the cluster-profilesvc-0/1 configs, and their
>> logs show clean shutdowns. I guess we need more debug output from
>> the server task as to what it thinks is not shutting down.
>
> Scott, the server shutdown problem must be related to the ant 1.7.1
> upgrade:
>
>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
I created a jira for this annoying issue:
https://jira.jboss.org/jira/browse/JBAS-5918
I've configured hudson to keep some more logs but I don't understand
why testsuite/output/tests.log gets overwritten with the following:
BUILD FAILED
/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-jrockit15/trunk/testsuite/build.xml:968:
Some servers failed to shutdown cleanly.
at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:142)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
at org.apache.tools.ant.Main.runBuild(Main.java:758)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
In my local run this file contains the test run output (i.e. what the
console would show, from
<record name="output/tests.log" append="no"
action="start"
loglevel="info"/>
to
<antcall target="tests-report"/>
<record name="output/tests.log" action="stop"/>
For some reason the following overwrites the file
<condition property="servers.shutdown.failed">
<and>
<not><isset
property="servers.shutdown.nocheck"/></not>
<isfileselected file="output/tests.log">
<or>
<contains text="Unable to shutdown server properly"/>
<not><contains
text="[server:stop]"/></not>
</or>
</isfileselected>
</and>
</condition>
<fail message="Some servers failed to shutdown cleanly."
if="servers.shutdown.failed"/>
8:47 a.m.
For the JBAS-5918, erroneous failed to stop msg, whatever is overwriting
the output/tests.log with binary content is what is causing the problem.
The condition expects that there are [server:stop] lines in the log, and
with the truncation with the binary content this is false. Still trying
to track down what is truncating the log. Using ant 1.7.0 also shows the
same problem.
For the JBAS-5625 profileservice tests, I pulled down the logs for the
failed 867 run, and I see the problem. Its JBAS-5921.
Dimitris Andreadis wrote:
Dimitris Andreadis wrote:
> Scott Stark wrote:
>> I don't see this in the test runs, and the only box I have
>> reproduced a failure on is due to an inability of the client to
>> reuse the 4446 port, and so the client remoting layer fails to
>> startup its streaming port. Its not even getting to the point of
>> trying a deployment.
>>
>> I'm now looking into why the current runs are failing to shutdown:
>>
>> tests-report:
>> [tar] Building tar:
>> /Users/svn/JBossHead/jboss-head/testsuite/output/2008-08-31.21-39.tgz
>>
>> BUILD FAILED
>> /Users/svn/JBossHead/jboss-head/testsuite/build.xml:969: Some
>> servers failed to shutdown cleanly.
>>
>> Total time: 179 minutes 36 seconds
>> [589][valkyrie: testsuite]$
>>
>> I have reproduced this, but the server is in fact shutting down. The
>> last servers run are the cluster-profilesvc-0/1 configs, and their
>> logs show clean shutdowns. I guess we need more debug output from
>> the server task as to what it thinks is not shutting down.
>
> Scott, the server shutdown problem must be related to the ant 1.7.1
> upgrade:
>
>
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test...
I created a jira for this annoying issue:
https://jira.jboss.org/jira/browse/JBAS-5918
I've configured hudson to keep some more logs but I don't understand
why testsuite/output/tests.log gets overwritten with the following:
BUILD FAILED
/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-5.0.x-TestSuite-jrockit15/trunk/testsuite/build.xml:968:
Some servers failed to shutdown cleanly.
at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:142)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1337)
at org.apache.tools.ant.Project.executeTarget(Project.java:1306)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1189)
at org.apache.tools.ant.Main.runBuild(Main.java:758)
at org.apache.tools.ant.Main.startAnt(Main.java:217)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
In my local run this file contains the test run output (i.e. what the
console would show, from
<record name="output/tests.log" append="no"
action="start"
loglevel="info"/>
to
<antcall target="tests-report"/>
<record name="output/tests.log" action="stop"/>
For some reason the following overwrites the file
<condition property="servers.shutdown.failed">
<and>
<not><isset
property="servers.shutdown.nocheck"/></not>
<isfileselected file="output/tests.log">
<or>
<contains text="Unable to shutdown server properly"/>
<not><contains
text="[server:stop]"/></not>
</or>
</isfileselected>
</and>
</condition>
<fail message="Some servers failed to shutdown cleanly."
if="servers.shutdown.failed"/>
5959
days inactive
5966
days old
jboss-development@lists.jboss.org
11 comments
5 participants
participants (5)
-
Adrian Brock -
Ales Justin -
Alexey Loubyansky -
Dimitris Andreadis -
Scott Stark