This was not a good proposal. Now people will stall their tests until <current_failures> - <his_fixed_test> < 100. :-)

You need to make Hudson happy first to get the Beer :) http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test... Ales Justin wrote:

It's really +3 (and those 3 might be transient). The +44 comes from a previous non-fully completed run, due to some test configuration problem. Still we are over 100. Sacha Labourey wrote:

I think it was the "outsider" Jeff Zhang that made the golden fix? I'll wait for the next runs to verify the winner (and I see more fixes coming in from Adrian...) http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-5.0.x-Test... (Beer - why didn't I think about this before? ;) Sacha Labourey wrote:

Should I now see 100%? Since I'm still getting failures: AS5_trunk_all boot: 16:57:48,323 ERROR [ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State} jboss.jca:name=JmsXA,service=ConnectionFactoryBinding -> jboss.jca:name=JmsXA,service=TxCM{Create:Configured} jboss.jca:name=JmsXA,service=ManagedConnectionFactory -> jboss.messaging:service=ServerPeer{Create:**ERROR**} jboss.jca:name=JmsXA,service=ManagedConnectionPool -> jboss.jca:name=JmsXA,service=ManagedConnectionFactory{Create:Configured} jboss.jca:name=JmsXA,service=TxCM -> jboss.jca:name=JmsXA,service=ManagedConnectionPool{Create:Configured} jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory -> jboss.messaging:service=ServerPeer{Create:**ERROR**} -> jboss.messaging:service=PostOffice{Create:Configured} jboss.messaging.connectionfactory:service=ClusteredConnectionFactory -> jboss.messaging:service=PostOffice{Create:Configured} -> jboss.messaging:service=ServerPeer{Create:**ERROR**} jboss.messaging.connectionfactory:service=ConnectionFactory -> jboss.messaging:service=PostOffice{Create:Configured} -> jboss.messaging:service=ServerPeer{Create:**ERROR**} jboss.messaging.destination:name=DLQ,service=Queue -> jboss.messaging:service=ServerPeer{Create:**ERROR**} -> jboss.messaging:service=PostOffice{Create:Configured} jboss.messaging.destination:name=ExpiryQueue,service=Queue -> jboss.messaging:service=PostOffice{Create:Configured} -> jboss.messaging:service=ServerPeer{Create:**ERROR**} jboss.messaging:service=PostOffice -> jboss.messaging:service=ServerPeer{Create:**ERROR**} jboss.mq:service=DestinationManager -> jboss.messaging:service=ServerPeer{Create:**ERROR**} *** CONTEXTS IN ERROR: Name -> Error jboss.messaging:service=ServerPeer -> **ERROR** | java.sql.SQLException: Table not found in statement [SELECT CNTR, ID FROM JBM_ID_CACHE WHERE NODE_ID = ?] Smoke tests raw: C:\projects\jboss5\trunk\testsuite>build smoke-tests-raw Calling ..\tools\bin\ant.bat smoke-tests-raw Buildfile: build.xml Overriding previous definition of reference to xerces.xerces.classpath Overriding previous definition of reference to apache.commons.classpath Overriding previous definition of reference to sax.classpath Overriding previous definition of reference to xdoclet.task.classpath Overriding previous definition of reference to gjt.jpl-util.classpath Overriding previous definition of reference to opennms.joesnmp.classpath Overriding previous definition of reference to jacorb.idl.classpath Overriding previous definition of reference to sleepycat.classpath Overriding previous definition of reference to apache.tomcat55.classpath Overriding previous definition of reference to trove.classpath Overriding previous definition of reference to qdox.classpath Overriding previous definition of reference to javassist.classpath Overriding previous definition of reference to hibernate3.classpath Overriding previous definition of reference to odmg.classpath Overriding previous definition of reference to cglib.classpath Overriding previous definition of reference to ejb3-persistence.classpath Overriding previous definition of reference to spring.classpath Overriding previous definition of reference to apache.ant.classpath Overriding previous definition of reference to jboss.test.classpath init: smoke-tests-raw: [echo] [echo] junit.timeout: 300000 [echo] jbosstest.iterationcount: 10 [echo] jbosstest.threadcount: 5 [echo] jbosstest.beancount: 5 [echo] [junit] Running org.jboss.test.aop.test.AOPUnitTestCase [junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 15,016 sec [junit] Running org.jboss.test.classloader.test.ScopingUnitTestCase [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 5,781 sec [junit] Running org.jboss.test.cts.test.BmpUnitTestCase [junit] Tests run: 11, Failures: 0, Errors: 11, Time elapsed: 1,438 sec [junit] Test org.jboss.test.cts.test.BmpUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.CmpUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0,89 sec [junit] Test org.jboss.test.cts.test.CmpUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.CtsCmp2OptionDUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1,078 sec [junit] Test org.jboss.test.cts.test.CtsCmp2OptionDUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.CtsCmp2UnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 4,828 sec [junit] Running org.jboss.test.cts.test.IndependentJarsUnitTestCase [junit] Tests run: 2, Failures: 0, Errors: 2, Time elapsed: 0,984 sec [junit] Test org.jboss.test.cts.test.IndependentJarsUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.MDBUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,875 sec [junit] Test org.jboss.test.cts.test.MDBUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.StatelessSessionBrokenCreateUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0,797 sec [junit] Test org.jboss.test.cts.test.StatelessSessionBrokenCreateUnitTestCase FAILED [junit] Running org.jboss.test.cts.test.StatelessSessionUnitTestCase [junit] Tests run: 8, Failures: 0, Errors: 8, Time elapsed: 0,875 sec [junit] Test org.jboss.test.cts.test.StatelessSessionUnitTestCase FAILED [junit] Running org.jboss.test.ejb3.test.SimpleSessionUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2,031 sec [junit] Running org.jboss.test.jbossmessaging.test.JBossMessagingJoramUnitTestCase [junit] Tests run: 198, Failures: 0, Errors: 196, Time elapsed: 3,281 sec [junit] Test org.jboss.test.jbossmessaging.test.JBossMessagingJoramUnitTestCase FAILED [junit] Running org.jboss.test.jca.test.BaseConnectionManagerUnitTestCase [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 26,875 sec [junit] Running org.jboss.test.jca.test.PoolingUnitTestCase [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0,781 sec [junit] Running org.jboss.test.jca.test.XADSUnitTestCase [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0,5 sec [junit] Running org.jboss.test.jmsra.test.RaJMSSessionUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 0,438 sec [junit] Test org.jboss.test.jmsra.test.RaJMSSessionUnitTestCase FAILED [junit] Running org.jboss.test.jmsra.test.RaQueueUnitTestCase [junit] Tests run: 4, Failures: 0, Errors: 4, Time elapsed: 1,859 sec [junit] Test org.jboss.test.jmsra.test.RaQueueUnitTestCase FAILED [junit] Running org.jboss.test.jmsra.test.RaSyncRecUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 0,515 sec [junit] Test org.jboss.test.jmsra.test.RaSyncRecUnitTestCase FAILED [junit] Running org.jboss.test.jmsra.test.RaTopicUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 0,406 sec [junit] Test org.jboss.test.jmsra.test.RaTopicUnitTestCase FAILED [junit] Running org.jboss.test.naming.test.SimpleUnitTestCase [junit] Tests run: 10, Failures: 0, Errors: 4, Time elapsed: 17,375 sec [junit] Test org.jboss.test.naming.test.SimpleUnitTestCase FAILED [junit] Running org.jboss.test.tm.test.TransactionManagerUnitTestCase [junit] Tests run: 28, Failures: 0, Errors: 0, Time elapsed: 1,14 sec [junit] Running org.jboss.test.web.test.WebIntegrationUnitTestCase [junit] Tests run: 0, Failures: 0, Errors: 1, Time elapsed: 3,047 sec [junit] Test org.jboss.test.web.test.WebIntegrationUnitTestCase FAILED BUILD SUCCESSFUL Total time: 1 minute 59 seconds Nice cheap way to get beer during EURO. If only it could be wired to Du Cerf. :-)

A few of the profileservice tests were fixed by restoring the SARDeployer ServiceMetaDataICF that was lost in the bootstrap.xml refactoring: commit -m "JBAS-5625, restore the SARDeployer ServiceMetaDataICF to obtain management interfaces from the mbean annotation element" /Users/svn/JBossHead/jboss-head/server/src/etc/conf/default/deployers.xml Sending /Users/svn/JBossHead/jboss-head/server/src/etc/conf/default/deployers.xml Transmitting file data ... Committed revision 74488. Dimitris Andreadis wrote:

On Thu, 2008-06-12 at 16:35 +0200, Ales Justin wrote: Yeh! Where's my beer for getting the testsuite from 40% to 90% before the Beta4 release? ;-) My bad, sorry. ;-( -- xxxxxxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Chief Scientist JBoss, a division of Red Hat xxxxxxxxxxxxxxxxxxxxxxxxxxxx

Sacha Labourey wrote: Thanks for not supporting under-age drinking. ;)

Beer in a cluster? Brian Stansberry wrote:

don't count on me to help here... On 06/12/2008 04:57 PM, Dimitris Andreadis wrote:

I'm only seeing 2 errors in the JmsDestinationUnitTestCase currently. [server:start] Starting server "profileservice" with command: [server:start] /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java -cp /Users/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/bin/run.jar:/Library/Java/Home/lib/tools.jar -Xms128m -Xmx512m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/Users/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/lib/endorsed -Djgroups.udp.ip_ttl=0 org.jboss.Main -c profileservice -b localhost [echo] Starting patternset=profileservice.includes config=profileservice [junit] Running org.jboss.test.profileservice.test.DeployUnitTestCase [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 3.342 sec [junit] Running org.jboss.test.profileservice.test.JmsDestinationUnitTestCase [junit] Tests run: 5, Failures: 2, Errors: 0, Time elapsed: 3.29 sec [junit] Test org.jboss.test.profileservice.test.JmsDestinationUnitTestCase FAILED [junit] Running org.jboss.test.profileservice.test.ProfileServiceUnitTestCase [junit] Tests run: 22, Failures: 0, Errors: 0, Time elapsed: 5.013 sec [server:stop] Shutting down server: profileservice [server:stop] Shutting down server: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java -cp /Users/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/bin/shutdown.jar:/Users/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/client/jbossall-client.jar:/Users/svn/JBossHead/jboss-head/build/output/jboss-5.0.0.CR1/client/jboss-common.jar org.jboss.Shutdown --server jnp://localhost:1099 --shutdown

I think it's the order here (profileservice tests) that matters. If there is some testEjb2xDeployment failure, all the next tests fail, since MainDeployer.checkComplete throws exception on that first error. The WS errors are my. I broke the VirtualFileAdaptor's serialization. :-( Fixing it now. Can someone (Scott, Alexey, Dimitris) do the metadata release then?

Cool. Will let you know when I'm done. Across ProfileService tests. At least that's what I saw yesterday - if ps.DeployUTC failed, then all the next one's failed as well - with that MD.checkComplete error. On unrelated note, the tests in PS do depend on order - addXY must definitely be before removeXY. How do we control this? With this: suite.addTest(new ProfileServiceUnitTestCase("testAddDataSource")); suite.addTest(new ProfileServiceUnitTestCase("testRemoveDataSource")); Is suite backed-up by list or set?

The TestSuite.addTest uses a Vector, so the add order is the test run order. That is why the setup explicitly adds the tests in the given order. Ales Justin wrote:

The problem is running this on Windows. Since we still/again have issue with file locking. Hence failure on duplicate deployments --> ejb3x standalone / ejb3x in ear. I tried the following hack - to get this off JDK's URL handling. // TODO - hack to get off JDK's url handling String urlString = contentURL.toExternalForm(); int p = urlString.indexOf(":/"); contentURL = new URL("vfszip" + urlString.substring(p)); But didn't help. :-( Scott Stark wrote:

What's your OS? Or what are the failures in DeployUTC (DUTC)? Since I've re-factored DUTC test to have few try/finally blocks, possibly cleaning up after failures. btw: how are these tests ordered? Randomly or alphabetically? If 2nd, let's rename DUTC to something starting with R or after. So we at least get relevant results on other tests. Is ClusteredDUTC even functional? Dimitris Andreadis wrote:

You'll get some more meaningful errors if you look at the profileservice logs, or you start the server by hand: Another thing I've noticed is the test modules are not removed from the deploy dir. ... 15:55:41,812 INFO [DeployHandler] Begin start, [testWarDeployment.war] 15:55:41,812 INFO [DeployHandler] Started: AbstractVFSDeployment(testWarDeploym ent.war) 15:55:42,093 INFO [TomcatDeployment] deploy, ctxPath=/testWarDeployment, vfsUrl =testWarDeployment.war 15:55:42,125 INFO [DeployHandler] End start, [testWarDeployment.war] 15:55:43,312 WARN [ManagementViewImpl] Failed to create ManagedDeployment for: testWarDeployment.war org.jboss.deployers.spi.DeploymentException: Context testWarDeployment.war not f ound at org.jboss.deployers.plugins.main.MainDeployerImpl.getDeploymentContex t(MainDeployerImpl.java:196) at org.jboss.deployers.plugins.main.MainDeployerImpl.getManagedDeploymen t(MainDeployerImpl.java:752) at org.jboss.profileservice.management.ManagementViewImpl.loadProfile(Ma nagementViewImpl.java:189) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRem otingInvocationHandler.java:82) at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.inv oke(ProfileServiceInvocationHandler.java:67) at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:849) at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(S erverThread.java:742) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(Se rverThread.java:695) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.j ava:549) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.jav a:230) 15:55:43,718 INFO [DeployHandler] stop, [testWarDeployment.war] 15:55:43,718 INFO [DeployHandler] Stopped: AbstractVFSDeployment(testWarDeploym ent.war) 15:55:43,718 INFO [TomcatDeployment] undeploy, ctxPath=/testWarDeployment, vfsU rl=testWarDeployment.war 15:55:43,843 INFO [DeployHandler] undeploy, [testWarDeployment.war] ... Dimitris Andreadis wrote:

Yes, that's due to that file locking. See my comment here: - http://jira.jboss.com/jira/browse/JBAS-5625 DeploymentProgressImpl: try { target.undeploy(deployment); status = new SerializableDeploymentStatus(command, StateType.COMPLETED); status.setTarget(target); status.setMessage("Completed undeploy for target: "+target); status.setCompleted(true); status.setRunning(true); currentStatus = status; event = new ProgressEvent(deployment, currentStatus); notify(event); } catch(Exception e) { status = new SerializableDeploymentStatus(command, StateType.FAILED); status.setTarget(target); status.setFailure(e); status.setFailed(true); currentStatus = status; ProgressEvent error = new ProgressEvent(deployment, currentStatus); notify(error); break; } } So instead of complete == true, you get false, since target.undeploy throws error not being able to delete file. And the test asserts on complete == true. Dimitris Andreadis wrote:

No. :-( I've tried every 'hack' I could think of in the 'path' of ProfileService/DeployHandler. Changing URI usage to direct File. vfszip hack. try/finally locks. ... Nothing. :-( You? Any ideas? Scott Stark wrote:

This looks like the same old locking problem as I can't remove the deploy/mail.rar when running on vista either. Scott Stark wrote:

The HDScanner talks to a different getModifiedDeployments implementation, so I suspect that is what is locking files. Its org.jboss.system.server.profileservice.repository.SerializableDeploymentRepository#getModifiedDeployments Ales Justin wrote:

Ales Justin wrote: I'm running on osx, so I'm not going to be seeing the file locking problems. The DUTC will be dependent on how the jvm method reflection is used. It should not be random, but can vary across vms. No, Brian just started that.

This is tracked here: http://jira.jboss.com/jira/browse/JBAS-5625 Ales Justin wrote: