Skip to content
[Jenkins]Jenkins
log in

Regression

jakartaeetck-run / jms_servlet / com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests.Test01_from_servlet (from jms_servlet)

Failing for the past 1 build (Since Aborted #5 )
Took 0 ms.

Error Message

test result: Failed. An error occurred during the Deployment phase for tests in this directory.

Stacktrace

test result: Failed. An error occurred during the Deployment phase for tests in this directory.

Standard Output

#Test Results (version 2)
#Wed Oct 13 07:54:12 UTC 2021
#-----testdescription-----
$file=/root/jakartaeetck/src/com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java
$root=/root/jakartaeetck/src
assertion_ids=JMS\:SPEC\:122  When a transaction commits, its atomic unit of input is acknowledged and its associated atomic unit of output is sent.(The term  transacted session  refers to the case where a session's commit and rollback methods are used to demarcate a transaction local to the session. In the case where a session's work is coordinated by an external transaction manager, a session's commit and rollback methods are not used and the result of a closed session's work is determined later by the transaction manager.)\nJMS\:SPEC\:265  The behaviour of a JMS session in respect of transactions and message acknowledgement is different for applications which run in a Java EE web or EJB container than it is for applications which run in a normal Java SE environment or in the Java EE application client container.\nThese differences also apply to JMS messaging context objects, since these incorporate a JMS session. \nWhen an application creates a JMS session or messaging context in a Java EE web or EJB container, and there is an active JTA transaction in progress, then the session that is created will participate in the JTA transaction and will be committed or rolled back when the JTA transaction is committed or rolled back. Any session parameters that are specified when creating the session or messaging context are ignored. The use of local transactions or client acknowledgement is not permitted.\nThis applies irrespective of whether the JTA transaction is demarcated automatically by the container or programmatically using methods on jakarta.transaction.UserTransaction. \nThe term "session parameters" here refers to the arguments that may be passed into a call to the createSession or createContext methods to specify whether the session should use a local transaction and, if the session is non-transacted, what the acknowledgement mode should be.\nWhen an application creates a JMS session or messaging context in a Java EE web or EJB container, and there is no active JTA transaction in progress, then the session that is created will be non-transacted and will be automatically-acknowledged. The use of local transactions or client acknowledgement is still not permitted. Parameters may be specified when creating the session or messaging context to specify whether the acknowledgement mode should be AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE. If any other session parameter values are specified they will be ignored and an acknowledgement mode of AUTO_ACKNOWLEDGE used. \nThe use of local transactions or client acknowledgement is not permitted in a Java EE web or EJB container even if there is no active JTA transaction because this would require applications to be written differently depending on whether there was a JTA transaction or not.\nJMS\:SPEC\:265.1  The JMS API provides the following methods to create a session which allow the session to be defined using either the two parameters transacted and acknowledgeMode or by the single parameter sessionMode. If these methods are called in a Java EE web or EJB container then these parameters will be overridden as described above.\n1) jakarta.jms.Connection method createSession(boolean transacted, int acknowledgeMode) \n2) jakarta.jms.QueueConnection method createQueueSession(boolean transacted, int acknowledgeMode)\n3) jakarta.jms.TopicConnection method createTopicSession(boolean transacted, int acknowledgeMode) \n4) jakarta.jms.Connection method createSession(int sessionMode)\nIt is recommended that applications that run in the Java EE web or EJB container create a session using the following method which does not specify a parameter\: jakarta.jms.Connection method createSession()\nJMS\:SPEC\:265.2  The JMS API provides the following methods to create a messaging context which allow the session to be defined using the single parameter sessionMode. If these methods are called in a Java EE web or EJB container then this parameter will be overridden as described above.\n1) jakarta.jms.ConnectionFactory method createContext(int sessionMode) \n2) jakarta.jms.ConnectionFactory method createContext(String userName, String password, int sessionMode)\nJMS\:SPEC\:265.3  The following method to create a messaging context from an existing messaging context is not permitted in a Java EE web or EJB container because it would create a second session on an existing connection, which is not permitted in a java EE web or EJB container.]\n1) jakarta.jms.JMSContext method createContext(int sessionMode) \nIt is recommended that applications that run in the Java EE web or EJb container creates a messaging context using one of the following methods which does do specify a sessionMode\:\n1) jakarta.jms.ConnectionFactory method createContext()  \n2) jakarta.jms.ConnectionFactory method createContext(String username, String password)\nJMS\:SPEC\:265.4  When programmatic transaction demarcation is being used, the session should be both created and used within an active JTA transaction.\nIf a session or messaging context is created when there  is an active JTA transaction, then after that transaction is committed or rolled back the session remains available for use in any subsequent JTA transaction until the session or messaging context is closed.\nHowever, if a session or messaging context is created when there is an active JTA transaction but is subsequently used to send or receive messages when there is no active JTA transaction then the behaviour is undefined. \nSimilarly, if a session or messaging context is created when there is no active JTA transaction but subsequently used to send or receive messages when there is an active JTA transaction then the behaviour is undefined.\nThe Bean Provider should not make use of the JMS request/reply paradigm (sending of a JMS message, followed by the synchronous receipt of a reply to that message) within a single transaction. Because a JMS message is typically not delivered to its final destination until the transaction commits, the receipt of the reply within the same transaction will not take place.\nJavaEE\:SPEC\:72  See assertion html documents.
classname=com.sun.ts.tests.jms.ee.ejbweb.xa.TransactionTests
direction=forward
finder=cts
id=Test01_from_servlet
keywords=all jms javaee jms_web_profile javaee_web_profile_optional Test01 servlet_vehicle forward
service_eetest=yes
testName=Test01
testProps=\ jms_timeout  user  password
test_directory=com/sun/ts/tests/jms/ee/ejbweb/xa

#-----environment-----
EJBServer1TxInteropEnabled=true
EJBServer2TxInteropEnabled=true
deployment_host.1=${orb.host}
deployment_host.2=${orb.host.ri}
deployment_port.1=${impl.vi.port}
deployment_port.2=${impl.ri.port}
derby.dbName=derbyDB
derby.driver=org.apache.derby.jdbc.ClientDriver
derby.passwd=cts1
derby.port=1527
derby.server=${orb.host}
derby.url=jdbc\:derby\://${derby.server}\:${derby.port}/${derby.dbName};create\=true
derby.user=cts1
harness.executeMode=0
harness.log.delayseconds=1
harness.log.port=2000
harness.log.traceflag=false
harness.socket.retry.count=10
harness.temp.directory=${ts.home}/tmp
http.server.supports.endpoint.publish=false
http.server.supports.endpoint.publish.2=false
impl.ri.port=${ri.admin.port}
impl.vi.port=${s1as.admin.port}
jakarta.persistence.jdbc.driver=${derby.driver}
jakarta.persistence.jdbc.password=${derby.passwd}
jakarta.persistence.jdbc.url=${derby.url}
jakarta.persistence.jdbc.user=${derby.user}
jakarta.persistence.provider=org.eclipse.persistence.jpa.PersistenceProvider
javaee.level=full
jms_timeout=10000
jpa.provider.implementation.specific.properties=eclipselink.logging.level\=OFF
namingServiceHost1=${orb.host}
namingServiceHost2=${orb.host.ri}
namingServicePort1=${orb.port}
namingServicePort2=${orb.port.ri}
orb.host=localhost
orb.host.ri=localhost
orb.port=3699
orb.port.ri=3701
password=j2ee
password1=${derby.passwd}
password2=${derby.passwd}
persistence.second.level.caching.supported=true
persistence.unit.name=CTS-EM
persistence.unit.name.2=JPATCK2
platform.mode=jakartaEE
porting.ts.HttpsURLConnection.class.1=com.sun.ts.lib.implementation.sun.javaee.SunRIHttpsURLConnection
porting.ts.HttpsURLConnection.class.2=com.sun.ts.lib.implementation.sun.javaee.SunRIHttpsURLConnection
porting.ts.deploy.class.1=com.sun.ts.lib.implementation.sun.javaee.glassfish.AutoDeployment
porting.ts.deploy.class.2=com.sun.ts.lib.implementation.sun.javaee.glassfish.AutoDeploymentSeparateVM
porting.ts.jms.class.1=com.sun.ts.lib.implementation.sun.javaee.SunRIJMSAdmin
porting.ts.jms.class.2=com.sun.ts.lib.implementation.sun.javaee.SunRIJMSAdmin
porting.ts.login.class.1=com.sun.ts.lib.implementation.sun.javaee.GlassFishLoginContext
porting.ts.login.class.2=com.sun.ts.lib.implementation.sun.javaee.GlassFishLoginContext
porting.ts.url.class.1=com.sun.ts.lib.implementation.sun.common.SunRIURL
porting.ts.url.class.2=com.sun.ts.lib.implementation.sun.common.SunRIURL
ri.admin.port=5858
s1as.admin.port=4848
securedWebServicePort=1044
securedWebServicePort.2=1045
ts.home=/root/jakartaeetck/bin/xml/../..
user=j2ee
user1=${derby.user}
user2=${derby.user}
variable.mapper=com.sun.el.lang.VariableMapperImpl
vi.admin.passwd=
vi.admin.user=admin
webServerHost=${orb.host}
webServerHost.2=${orb.host.ri}
webServerPort=8001
webServerPort.2=8002
wsdlRepository1=${harness.temp.directory}/wsdlRepository1
wsdlRepository2=${harness.temp.directory}/wsdlRepository2

#-----testresult-----
description=file\:/root/jakartaeetck/src/com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java\#Test01_from_servlet
end=Wed Oct 13 07\:54\:12 UTC 2021
environment=ts_unix
execStatus=Failed. An error occurred during the Deployment phase for tests in this directory.
harnessLoaderMode=Classpath Loader
harnessVariety=Full Bundle
javatestOS=Linux 5.12.7-300.fc34.x86_64 (amd64)
javatestVersion=5.0
script=com.sun.ts.lib.harness.TSScript
sections=script_messages Deployment TestRun
start=Wed Oct 13 07\:54\:12 UTC 2021
test=com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java\#Test01_from_servlet
timeoutSeconds=1200
totalTime=14
work=/root/jakartaeetck-work/jms/com/sun/ts/tests/jms/ee/ejbweb/xa

#section:script_messages
----------messages:(0/0)----------

#section:Deployment
----------messages:(0/0)----------
----------log:(21/1376)----------
Undeploying apps...
AutoDeployment.isDeployed()
AutoDeployment.isDeployed()
AutoDeployment.isDeployed()
Search for s1as runtime files match:`transaction_jsp_vehicle.ear`
Valid runtime files after sweep:
/root/jakartaeetck/bin/xml/../../dist/com/sun/ts/tests/jms/ee/ejbweb/xa/transaction_jsp_vehicle_web.war.sun-web.xml
Search for s1as runtime files match:`transaction_servlet_vehicle.ear`
Valid runtime files after sweep:
/root/jakartaeetck/bin/xml/../../dist/com/sun/ts/tests/jms/ee/ejbweb/xa/transaction_servlet_vehicle_web.war.sun-web.xml
Search for s1as runtime files match:`transaction_ejb_vehicle.ear`
Valid runtime files after sweep:
/root/jakartaeetck/bin/xml/../../dist/com/sun/ts/tests/jms/ee/ejbweb/xa/transaction_ejb_vehicle_client.jar.sun-application-client.xml
/root/jakartaeetck/bin/xml/../../dist/com/sun/ts/tests/jms/ee/ejbweb/xa/transaction_ejb_vehicle_ejb.jar.sun-ejb-jar.xml
Deploying apps for forward rebuildable...
Search for s1as runtime files match:`transaction_ejb_vehicle.ear`
Valid runtime files after sweep:
/root/jakartaeetck/bin/xml/../../tmp/transaction_ejb_vehicle_client.jar.sun-application-client.xml
/root/jakartaeetck/bin/xml/../../tmp/transaction_ejb_vehicle_ejb.jar.sun-ejb-jar.xml
getAppNameFromApplicationXML() returning "null"
Deployment of app(s) from:  /root/jakartaeetck/bin/xml/../../dist/com/sun/ts/tests/jms/ee/ejbweb/xa failed!
result: Passed. Deployment phase completed. However, check the output above to see if actual deployment passed or failed.

#section:TestRun
----------messages:(0/0)----------
----------log:(15/1136)----------
com.sun.ts.lib.porting.TSDeploymentException: The following error occurred while executing this line:
/root/jakartaeetck/bin/xml/impl/glassfish/deploy.xml:152: The following error occurred while executing this line:
/root/jakartaeetck/bin/xml/impl/glassfish/deploy.xml:200: Deployment timeout reached - 480 seconds.

	at com.sun.ts.lib.implementation.sun.javaee.glassfish.AutoDeployment.deploy(AutoDeployment.java:227)
	at com.sun.ts.lib.harness.SuiteSynchronizer.continueToDeployApps(SuiteSynchronizer.java:1104)
	at com.sun.ts.lib.harness.SuiteSynchronizer.deployApps(SuiteSynchronizer.java:716)
	at com.sun.ts.lib.harness.SuiteSynchronizer.doDeployment(SuiteSynchronizer.java:387)
	at com.sun.ts.lib.harness.TSHarnessObserver.startingTest(TSHarnessObserver.java:367)
	at com.sun.javatest.Harness$Notifier.startingTest(Harness.java:995)
	at com.sun.javatest.TestRunner.notifyStartingTest(TestRunner.java:212)
	at com.sun.javatest.DefaultTestRunner.runTest(DefaultTestRunner.java:167)
	at com.sun.javatest.DefaultTestRunner.access$100(DefaultTestRunner.java:43)
	at com.sun.javatest.DefaultTestRunner$1.run(DefaultTestRunner.java:66)

result: Not run. Test running...


test result: Failed. An error occurred during the Deployment phase for tests in this directory.