[JBoss JIRA] (WFCORE-2998) levelRange in filter-spec is documented wrong and makes Wildfly startup fail silently
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2998?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-2998:
---------------------------------------
The problem is the error happens while configuring logging so it can't really report it at this point. I've got an issue filed on the log manager (LOGMGR-150) to support a better way of reporting errors. Until that gets fixed there's not a lot we can do at this point.
When I start the current upstream I do at least see the error:
{code}
11:10:27,898 INFO [org.xnio.nio] (MSC service thread 1-7) XNIO NIO Implementation Version 3.5.0.CR1
11:10:27,915 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "logging"),
("console-handler" => "CONSOLE")
]): java.lang.IllegalArgumentException: Max level cannot be less than min level
at org.jboss.logmanager.filters.LevelRangeFilter.<init>(LevelRangeFilter.java:49)
at org.jboss.logmanager.config.LogContextConfigurationImpl.parseFilterExpression(LogContextConfigurationImpl.java:645)
at org.jboss.logmanager.config.LogContextConfigurationImpl.resolveFilter(LogContextConfigurationImpl.java:731)
at org.jboss.logmanager.config.LogContextConfigurationImpl.resolveFilter(LogContextConfigurationImpl.java:739)
at org.jboss.logmanager.config.HandlerConfigurationImpl$3.validate(HandlerConfigurationImpl.java:166)
at org.jboss.logmanager.config.HandlerConfigurationImpl$3.validate(HandlerConfigurationImpl.java:164)
at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:335)
at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:288)
at org.jboss.as.logging.logmanager.ConfigurationPersistence.prepare(ConfigurationPersistence.java:303)
at org.jboss.as.logging.LoggingOperations$CommitOperationStepHandler.execute(LoggingOperations.java:97)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:978)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:724)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:448)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:516)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:468)
at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:430)
at org.jboss.as.server.ServerService.boot(ServerService.java:437)
at org.jboss.as.server.ServerService.boot(ServerService.java:396)
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:370)
at java.lang.Thread.run(Thread.java:748)
{code}
> levelRange in filter-spec is documented wrong and makes Wildfly startup fail silently
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-2998
> URL: https://issues.jboss.org/browse/WFCORE-2998
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 2.2.1.Final
> Reporter: Gregor Rosenauer
> Assignee: James Perkins
> Labels: check, configuration, logging, startup
>
> Linux 4.8.0-54-generic #57-Ubuntu SMP Wed May 24 10:21:44 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> Oracle JDK 8 build 1.8.0_131-b11
> running in a docker container using Docker 1.12.6, build 78d1802
> Trying to configure e.g. a console-appender with a logging filter as described in
> [Wildfly 10 Logging Configuration|https://docs.jboss.org/author/display/WFLY10/Logging+Config...]
> The server will startup and happily parse the configuration, but then exit without any error:
> {{2017-06-22 15:12:28,185 DEBG fd 7 closed, stopped monitoring <POutputDispatcher at 140706226583888 for <Subprocess at 140706228894320 with name wildfly in state RUNNING> (stdout)>
> 2017-06-22 15:12:28,186 DEBG fd 9 closed, stopped monitoring <POutputDispatcher at 140706226584392 for <Subprocess at 140706228894320 with name wildfly in state RUNNING> (stderr)>}}
> The culprit is the *order* of the levels in the range expression, which is the wrong way around.
> The correct order (which makes more sense anyway) is e.g. {{[DEBUG,WARN)}} not {{[WARN,DEBUG)}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7127?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-7127:
------------------------------------
[https://community.jboss.org/en/wildfly?view=discussion] is also a good place to discuss issues like this, that might be seen by more people. That can help ensure that the issue is examined by others on the WildFly team. Although, for this jira, perhaps the better place is [http://forum.hibernate.org] to discuss the cause and possible solutions.]
> CMR collection gets corrupted in 2LC on certain concurrent access
> -----------------------------------------------------------------
>
> Key: WFLY-7127
> URL: https://issues.jboss.org/browse/WFLY-7127
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JPA / Hibernate, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Ubuntu Linux 15.10. Java 1.8.0_66
> Reporter: Jari Juslin
> Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml
>
>
> With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted.
> Steps to reproduce:
> 1) Make sure the CMR collection is not in cache.
> 2) Start a read-only transaction accessing the said collection.
> 3) In a separate transaction delete an element from that collection.
> 4) End the read-only transaction.
> 5) Read the resulting collection. It now throws EntityNotFoundException.
> My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC.
> Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB.
> For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern.
> The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7127?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-7127:
-------------------------------
Comment: was deleted
(was: See my earlier comment from today, about needing answers to [~gbadner] question.)
> CMR collection gets corrupted in 2LC on certain concurrent access
> -----------------------------------------------------------------
>
> Key: WFLY-7127
> URL: https://issues.jboss.org/browse/WFLY-7127
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JPA / Hibernate, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Ubuntu Linux 15.10. Java 1.8.0_66
> Reporter: Jari Juslin
> Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml
>
>
> With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted.
> Steps to reproduce:
> 1) Make sure the CMR collection is not in cache.
> 2) Start a read-only transaction accessing the said collection.
> 3) In a separate transaction delete an element from that collection.
> 4) End the read-only transaction.
> 5) Read the resulting collection. It now throws EntityNotFoundException.
> My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC.
> Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB.
> For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern.
> The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7127?page=com.atlassian.jira.plugin.... ]
Scott Marlow resolved WFLY-7127.
--------------------------------
Resolution: Incomplete Description
See my earlier comment from today, about needing answers to [~gbadner] question.
> CMR collection gets corrupted in 2LC on certain concurrent access
> -----------------------------------------------------------------
>
> Key: WFLY-7127
> URL: https://issues.jboss.org/browse/WFLY-7127
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JPA / Hibernate, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Ubuntu Linux 15.10. Java 1.8.0_66
> Reporter: Jari Juslin
> Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml
>
>
> With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted.
> Steps to reproduce:
> 1) Make sure the CMR collection is not in cache.
> 2) Start a read-only transaction accessing the said collection.
> 3) In a separate transaction delete an element from that collection.
> 4) End the read-only transaction.
> 5) Read the resulting collection. It now throws EntityNotFoundException.
> My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC.
> Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB.
> For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern.
> The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7127?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-7127:
------------------------------------
Please reopen this issue when you have answers for [~gbadner]. Thanks, Scott
> CMR collection gets corrupted in 2LC on certain concurrent access
> -----------------------------------------------------------------
>
> Key: WFLY-7127
> URL: https://issues.jboss.org/browse/WFLY-7127
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JPA / Hibernate, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Ubuntu Linux 15.10. Java 1.8.0_66
> Reporter: Jari Juslin
> Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml
>
>
> With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted.
> Steps to reproduce:
> 1) Make sure the CMR collection is not in cache.
> 2) Start a read-only transaction accessing the said collection.
> 3) In a separate transaction delete an element from that collection.
> 4) End the read-only transaction.
> 5) Read the resulting collection. It now throws EntityNotFoundException.
> My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC.
> Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB.
> For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern.
> The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8847) SPNEGOLoginModuleTestCase#testIdentityPropagation fails with IBM on some machines
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-8847?page=com.atlassian.jira.plugin.... ]
Kabir Khan reassigned WFLY-8847:
--------------------------------
Assignee: Martin Choma
> SPNEGOLoginModuleTestCase#testIdentityPropagation fails with IBM on some machines
> ---------------------------------------------------------------------------------
>
> Key: WFLY-8847
> URL: https://issues.jboss.org/browse/WFLY-8847
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Martin Choma
> Priority: Minor
> Fix For: 11.0.0.Beta1
>
>
> IBM java sends address in delegated kerberos ticket. ApacheDS includes this address into ticket and check that address with address of client (taken from connection). On some machines, these addresses doesn't match.
> Those are machines when there are several virtual IPs and if node0 is set to non-first IP address, ApacheDS address check fails.
> See details in https://issues.apache.org/jira/browse/DIRSERVER-2156
> {code}
> [31m15:14:11,302 ERROR [io.undertow.request] (default task-32) UT005023: Exception handling request to /f1eb2aa6-5139-4bce-bad8-ad9a49d3912f/protected/PropagateIdentityServlet: javax.servlet.ServletException: Propagation failed.
> at org.jboss.eapqe.krbldap.eap.deployments.servlets.PropagateIdentityServlet.doGet(PropagateIdentityServlet.java:87)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> Caused by: org.ietf.jgss.GSSException, major code: 11, minor code: 0
> major string: General failure, unspecified at GSSAPI level
> minor string: Error: java.lang.Exception: Error: com.ibm.security.krb5.KrbException, status code: 38
> message: Incorrect net address
> at com.ibm.security.jgss.i18n.I18NException.throwGSSException(I18NException.java:33)
> at com.ibm.security.jgss.mech.krb5.g.a(g.java:23)
> at com.ibm.security.jgss.mech.krb5.g.initSecContext(g.java:814)
> at com.ibm.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:337)
> at com.ibm.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:437)
> at org.jboss.eapqe.krbldap.utils.krb.GSSTestClient.getName(GSSTestClient.java:100)
> at org.jboss.eapqe.krbldap.eap.deployments.servlets.PropagateIdentityServlet.doGet(PropagateIdentityServlet.java:85)
> ... 32 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7127) CMR collection gets corrupted in 2LC on certain concurrent access
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7127?page=com.atlassian.jira.plugin.... ]
Scott Marlow reassigned WFLY-7127:
----------------------------------
Assignee: (was: Scott Marlow)
> CMR collection gets corrupted in 2LC on certain concurrent access
> -----------------------------------------------------------------
>
> Key: WFLY-7127
> URL: https://issues.jboss.org/browse/WFLY-7127
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JPA / Hibernate, Transactions
> Affects Versions: 10.1.0.Final
> Environment: Ubuntu Linux 15.10. Java 1.8.0_66
> Reporter: Jari Juslin
> Attachments: infinispan_cmr_corruption_repro.tar.gz, standalone.xml
>
>
> With certain parallel read and write access to same CMR collection it gets corrupted in Hibernate second level cache. After the event of corruption, any read access to that CMR collection ends up in Exception until the cache is cleared manually or Wildfly restarted.
> Steps to reproduce:
> 1) Make sure the CMR collection is not in cache.
> 2) Start a read-only transaction accessing the said collection.
> 3) In a separate transaction delete an element from that collection.
> 4) End the read-only transaction.
> 5) Read the resulting collection. It now throws EntityNotFoundException.
> My understanding is that what happens is that the read-only transaction is read-only from the perspective of the database, so the system handles it as such. However, because for the 2LC it is actually a write transaction, when the transaction ends, the contents of the CMR collection visible to this transaction get committed to 2LC. If the write transaction ends before the read-only transaction, the old version of the collection stays in the 2LC.
> Now, as the CMR collection contains an element already deleted from the DB, any attempt to manifest the collection results in EntityNotFoundException as the child element no longer exists in the DB.
> For sake of repeatibility the test case here manually spawns threads to cause the effect. In real use, of course, this happens randomly when two different threads spawned by Wildfly happen to interleave with exactly a right kind of pattern.
> The tar ball contains everything needed to reproduce the bug, including SQL dump of the MySQL/InnoDB database. The easiest way to run the testcase is to take Wildfly 10.1.0.Final and use the provided standalone.xml, add MySQL driver, import the DB with the provided SQL and then deploy the included packaged testcase.ear.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8951) Fix and re-enable IIOPTimeoutTestCase
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8951?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-8951:
----------------------------------------
[~tomekadamski] I see this was a pull request to transaction client, is that the version tagged and merged recently or is a subsequent release needed?
> Fix and re-enable IIOPTimeoutTestCase
> -------------------------------------
>
> Key: WFLY-8951
> URL: https://issues.jboss.org/browse/WFLY-8951
> Project: WildFly
> Issue Type: Bug
> Components: IIOP, Transactions
> Affects Versions: 11.0.0.Alpha1
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Priority: Blocker
>
> {{IIOPTimeoutTestCase}} is currenty disabled using {{DisableInvocationTestUtil.disable()}} because it fails as follows:
> {code}
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.321 sec <<< FAILURE! - in org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase
> timeoutStateless(org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase) Time elapsed: 1.193 sec <<< FAILURE!
> java.lang.AssertionError: Expecting two rollback happened on XA resources expected:<2> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateless(IIOPTimeoutTestCase.java:135)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Results :
> Failed tests:
> IIOPTimeoutTestCase.timeoutStateless:135 Expecting two rollback happened on XA resources expected:<2> but was:<0>
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0
> {code}
> This needs to be fixed and the test needs to be re-enabled.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8951) Fix and re-enable IIOPTimeoutTestCase
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8951?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-8951:
-----------------------------------
Comment: was deleted
(was: [~tomekadamski] I see this was a pull request to transaction client, is that the version tagged and merged recently or is a subsequent release needed?)
> Fix and re-enable IIOPTimeoutTestCase
> -------------------------------------
>
> Key: WFLY-8951
> URL: https://issues.jboss.org/browse/WFLY-8951
> Project: WildFly
> Issue Type: Bug
> Components: IIOP, Transactions
> Affects Versions: 11.0.0.Alpha1
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
> Priority: Blocker
>
> {{IIOPTimeoutTestCase}} is currenty disabled using {{DisableInvocationTestUtil.disable()}} because it fails as follows:
> {code}
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.321 sec <<< FAILURE! - in org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase
> timeoutStateless(org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase) Time elapsed: 1.193 sec <<< FAILURE!
> java.lang.AssertionError: Expecting two rollback happened on XA resources expected:<2> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateless(IIOPTimeoutTestCase.java:135)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:374)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:367)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:319)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:312)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:426)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> Results :
> Failed tests:
> IIOPTimeoutTestCase.timeoutStateless:135 Expecting two rollback happened on XA resources expected:<2> but was:<0>
> Tests run: 4, Failures: 1, Errors: 0, Skipped: 0
> {code}
> This needs to be fixed and the test needs to be re-enabled.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-7835) StatefulSessionSynchronizationInterceptor can`t see that current tx replaced by arjuna`s tx reaper and can`t aquire it`s own component lock
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-7835?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned WFLY-7835:
-----------------------------------
Assignee: Amos Feng (was: Tom Jenkinson)
> StatefulSessionSynchronizationInterceptor can`t see that current tx replaced by arjuna`s tx reaper and can`t aquire it`s own component lock
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7835
> URL: https://issues.jboss.org/browse/WFLY-7835
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 10.0.0.Final
> Environment: wildfly 10.0.0.Final
> java 8u101
> narayana-jts-integration-5.2.12.Final
> SFSB with CMT
> Reporter: kostd kostd
> Assignee: Amos Feng
> Priority: Minor
> Attachments: log-fragment-7835
>
>
> full log will be attached, now short chronology:
> 1. ~02:20 default task-186 starts request processing. During request where was call to ExtendedPersistenceContainer (SFSB with CMT).
> So StatefulSessionSynchronizationInterceptor#processInvocation called and component lock aquired (owner = current tx, see StatefulSessionSynchronizationInterceptor#getLockOwner). This event not catched in logfile, because regular behavour not logged.
> 2. 02:39:26: tx timeout reached (20min), so arjuna`s reaper thread trying cancel tx. Now current tx == null ( ?):
> {quote}
> 02:39:26,882 WARN [arjuna] (Transaction Reaper Worker 73) ARJUNA012381: Action id 0:ffff0aa010c9:22fba49e:5848e8ad:446f10c completed with multiple threads - thread default task-186 was in progress with java.net.SocketInputStream.socketRead0(Native Method)
> {quote}
> 3. 02:39:32: query timeout in task thread reached:
> {quote}
> 02:39:32,806 ERROR [sql] (default task-186) SQL query error: 2c344b99 (executed in 1 205 917 ms): java.sql.SQLTimeoutException: ORA-01013: пользователем запрошена отмена текущей операции
> {quote}
> this event seems not interest.
> 4. 02:39:32: arjuna`s reaper thread trying to release component lock but fails because does not own`em:
> {quote}
> 02:39:32,808 WARN [txn] (Transaction Reaper Worker 73) WFLYTX0027: The pre-jca synchronization org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization@58e72087 associated with tx TransactionImple < ac, BasicAction: 0:ffff0aa010c9:22fba49e:5848e8ad:446f10c status: ActionStatus.ABORTED > failed during after completion: java.lang.IllegalMonitorStateException
> {quote}
> 5. 02:39: task-thread contiunes request processing: hibernate noticed that current tx replaced(removed) by arjuna`s reaper:
> {quote}
> {code}
> 02:39:32,822 WARN [lifecycle] (default task-186) #{viewModel.save}: javax.persistence.PersistenceException: org.hibernate.HibernateException: Transaction was rolled back in a different thread!: javax.faces.FacesException: #{viewModel.save}: javax.persistence.PersistenceException: org.hibernate.HibernateException: Transaction was rolled back in a different thread!
> {code}
> {quote}
> 6. but StatefulSessionSynchronizationInterceptor not noticed. StatefulSessionSynchronizationInterceptor trying to aquire same lock, but owner changed, was current tx and now current thread (?):
> {quote}
> 02:39:37,827 ERROR [invocation] (default task-186) WFLYEJB0034: EJB Invocation failed on component ExtendedPersistenceContainer for method public javax.persistence.EntityManager ru.argustelecom.system.inf.transaction.ExtendedPersistenceContainer.getEntityManager(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on ExtendedPersistenceContainer - could not obtain lock within 5000 MILLISECONDS
> {quote}
> So, next two clauses is bug-behavour or by-desighn behavour:
> c1. arjuna`s reaper thread trying release component lock through StatefulSessionSynchronizationInterceptor, but does not owns this lock.
> c2. StatefulSessionSynchronizationInterceptor can`t see that current tx replaced and trying to aquire it`s own component lock with different owners. In second try lock cannot be aquired during any timeout
> ?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months