[JBoss JIRA] (WFLY-6109) Using OPTIMISTIC locking results in "ISPN000112: exception while committing: javax.transaction.xa.XAException" on responseDone()
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6109?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-6109:
--------------------------------------
The call stack to where the transaction is removed from the table (prior to the above exception):
{noformat}
"DeploymentScanner-threads - 1@14421" prio=5 tid=0x3b nid=NA runnable
java.lang.Thread.State: RUNNABLE
at java.security.AccessController.getStackAccessControlContext(AccessController.java:-1)
at java.security.AccessController.getContext(AccessController.java:820)
at org.jboss.as.controller.SecurityActions.getCaller(SecurityActions.java:47)
at org.jboss.as.controller.AbstractOperationContext.getCaller(AbstractOperationContext.java:1138)
at org.jboss.as.controller.OperationContextImpl.getBasicAuthorizationResponse(OperationContextImpl.java:1730)
at org.jboss.as.controller.OperationContextImpl.authorize(OperationContextImpl.java:1659)
at org.jboss.as.controller.OperationContextImpl.readResourceFromRoot(OperationContextImpl.java:838)
at org.jboss.as.controller.OperationContextImpl.readResource(OperationContextImpl.java:823)
at org.jboss.as.controller.operations.global.ReadChildrenResourcesHandler.execute(ReadChildrenResourcesHandler.java:93)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:659)
at org.jboss.as.controller.ModelControllerImpl$3.execute(ModelControllerImpl.java:649)
at org.jboss.as.server.deployment.scanner.DefaultDeploymentOperations.getUnrelatedDeployments(DefaultDeploymentOperations.java:106)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1615)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$ScanContext.<init>(FileSystemDeploymentService.java:1563)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:568)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:489)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentScanRunnable.run(FileSystemDeploymentService.java:250)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{noformat}
> Using OPTIMISTIC locking results in "ISPN000112: exception while committing: javax.transaction.xa.XAException" on responseDone()
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6109
> URL: https://issues.jboss.org/browse/WFLY-6109
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> {noformat}
> 15:34:39,087 WARN [org.infinispan.transaction.tm.DummyTransaction] (default task-1) ISPN000112: exception while committing: javax.transaction.xa.XAException
> at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidateImpl(TransactionXaAdapter.java:242)
> at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidate(TransactionXaAdapter.java:235)
> at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:103)
> at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:389)
> at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:435)
> at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:314)
> at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:105)
> at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:73)
> at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.close(ActiveTransactionBatch.java:48)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:77)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:768)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6109) Using OPTIMISTIC locking results in "ISPN000112: exception while committing: javax.transaction.xa.XAException" on responseDone()
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6109:
------------------------------------
Summary: Using OPTIMISTIC locking results in "ISPN000112: exception while committing: javax.transaction.xa.XAException" on responseDone()
Key: WFLY-6109
URL: https://issues.jboss.org/browse/WFLY-6109
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.Final
Reporter: Radoslav Husar
Assignee: Paul Ferraro
{noformat}
15:34:39,087 WARN [org.infinispan.transaction.tm.DummyTransaction] (default task-1) ISPN000112: exception while committing: javax.transaction.xa.XAException
at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidateImpl(TransactionXaAdapter.java:242)
at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidate(TransactionXaAdapter.java:235)
at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:103)
at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:389)
at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:435)
at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:314)
at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:105)
at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:73)
at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.close(ActiveTransactionBatch.java:48)
at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:77)
at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:768)
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6109) Using OPTIMISTIC locking results in "ISPN000112: exception while committing: javax.transaction.xa.XAException" on responseDone()
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6109?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-6109:
------------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
> Using OPTIMISTIC locking results in "ISPN000112: exception while committing: javax.transaction.xa.XAException" on responseDone()
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6109
> URL: https://issues.jboss.org/browse/WFLY-6109
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> {noformat}
> 15:34:39,087 WARN [org.infinispan.transaction.tm.DummyTransaction] (default task-1) ISPN000112: exception while committing: javax.transaction.xa.XAException
> at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidateImpl(TransactionXaAdapter.java:242)
> at org.infinispan.transaction.xa.TransactionXaAdapter.getLocalTransactionAndValidate(TransactionXaAdapter.java:235)
> at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:103)
> at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:389)
> at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:435)
> at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:314)
> at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:105)
> at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:73)
> at org.wildfly.clustering.ee.infinispan.ActiveTransactionBatch.close(ActiveTransactionBatch.java:48)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:77)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:768)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:557)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:331)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1343) [1.x] Memory leak in host controller
by Aparna Chaudhary (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1343?page=com.atlassian.jira.plugi... ]
Aparna Chaudhary commented on WFCORE-1343:
------------------------------------------
Thank you [~brian.stansberry] for your quick response.
> [1.x] Memory leak in host controller
> ------------------------------------
>
> Key: WFCORE-1343
> URL: https://issues.jboss.org/browse/WFCORE-1343
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Final
> Reporter: Aparna Chaudhary
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 1.0.2.Final
>
> Attachments: WFCORE-992-HC-Leak.PNG
>
>
> The ManagedServerProxy class in host-controller contains a memory leak. The leak can be reproduced by performing multiple requests to HTTP management API.
> {noformat}
> http://<host>:9990/management/host/host0/server/server0/core-service/platform-mbean/type/memory?include-runtime=true
> {noformat}
> Applying the fix proposed in WFCORE-992 solves the leak.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6099) JPA's persistence.xml is deployed before datasources are created through application.xml
by Renann Prado (JIRA)
[ https://issues.jboss.org/browse/WFLY-6099?page=com.atlassian.jira.plugin.... ]
Renann Prado edited comment on WFLY-6099 at 2/1/16 1:00 PM:
------------------------------------------------------------
I'll try soon and let you know. Thanks!
However I still find strange how this is working:
In *standalone.xml*:
{code:xml}
<datasource jta="true" jndi-name="java:jboss/datasources/TestDS" pool-name="TestDS" enabled="true" use-ccm="true">
<connection-url>jdbc:mariadb://mariadbvm:3306/test_db</connection-url>
<driver-class>org.mariadb.jdbc.Driver</driver-class>
<driver>mariadb-java-client-1.3.4.jar</driver>
<security>
<user-name>root</user-name>
<password>123</password>
</security>
<validation>
<valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
<background-validation>true</background-validation>
<exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
</validation>
</datasource>
{code}
As you can see the driver class is "wrong".
was (Author: renannp):
I'll try soon and let you know. Thanks!
However I still find strange how this is working:
In *standalone.xml*:
{code:xml}
<datasource jta="true" jndi-name="java:jboss/datasources/TestDS" pool-name="TestDS" enabled="true" use-ccm="true">
<connection-url>jdbc:mariadb://107.155.108.92:3306/test_db</connection-url>
<driver-class>org.mariadb.jdbc.Driver</driver-class>
<driver>mariadb-java-client-1.3.4.jar</driver>
<security>
<user-name>root</user-name>
<password>123</password>
</security>
<validation>
<valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
<background-validation>true</background-validation>
<exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
</validation>
</datasource>
{code}
As you can see the driver class is "wrong".
> JPA's persistence.xml is deployed before datasources are created through application.xml
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6099
> URL: https://issues.jboss.org/browse/WFLY-6099
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Renann Prado
> Assignee: Scott Marlow
> Attachments: server_with_mysql_driver.log
>
>
> Please refer to discussion
> https://developer.jboss.org/thread/267371
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6099) JPA's persistence.xml is deployed before datasources are created through application.xml
by Renann Prado (JIRA)
[ https://issues.jboss.org/browse/WFLY-6099?page=com.atlassian.jira.plugin.... ]
Renann Prado edited comment on WFLY-6099 at 2/1/16 12:55 PM:
-------------------------------------------------------------
I'll try soon and let you know. Thanks!
However I still find strange how this is working:
In *standalone.xml*:
{code:xml}
<datasource jta="true" jndi-name="java:jboss/datasources/TestDS" pool-name="TestDS" enabled="true" use-ccm="true">
<connection-url>jdbc:mariadb://107.155.108.92:3306/test_db</connection-url>
<driver-class>org.mariadb.jdbc.Driver</driver-class>
<driver>mariadb-java-client-1.3.4.jar</driver>
<security>
<user-name>root</user-name>
<password>123</password>
</security>
<validation>
<valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
<background-validation>true</background-validation>
<exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
</validation>
</datasource>
{code}
As you can see the driver class is "wrong".
was (Author: renannp):
I'll try soon and let you know. Thanks!
However I still find strange how this is working:
In *standalone.xml*:
{code:xml}
<datasource jta="true" jndi-name="java:jboss/datasources/TestDS" pool-name="TestDS" enabled="true" use-ccm="true">
<connection-url>jdbc:mariadb://107.155.108.92:3306/test_db</connection-url>
<driver-class>org.mariadb.jdbc.Driver</driver-class>
<driver>mariadb-java-client-1.3.4.jar</driver>
<security>
<user-name>root</user-name>
<password>123</password>
</security>
<validation>
<valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
<background-validation>true</background-validation>
<exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
</validation>
</datasource>
{code}
> JPA's persistence.xml is deployed before datasources are created through application.xml
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6099
> URL: https://issues.jboss.org/browse/WFLY-6099
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Renann Prado
> Assignee: Scott Marlow
> Attachments: server_with_mysql_driver.log
>
>
> Please refer to discussion
> https://developer.jboss.org/thread/267371
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6099) JPA's persistence.xml is deployed before datasources are created through application.xml
by Renann Prado (JIRA)
[ https://issues.jboss.org/browse/WFLY-6099?page=com.atlassian.jira.plugin.... ]
Renann Prado commented on WFLY-6099:
------------------------------------
I'll try soon and let you know. Thanks!
However I still find strange how this is working:
In *standalone.xml*:
{code:xml}
<datasource jta="true" jndi-name="java:jboss/datasources/TestDS" pool-name="TestDS" enabled="true" use-ccm="true">
<connection-url>jdbc:mariadb://107.155.108.92:3306/test_db</connection-url>
<driver-class>org.mariadb.jdbc.Driver</driver-class>
<driver>mariadb-java-client-1.3.4.jar</driver>
<security>
<user-name>root</user-name>
<password>123</password>
</security>
<validation>
<valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"/>
<background-validation>true</background-validation>
<exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"/>
</validation>
</datasource>
{code}
> JPA's persistence.xml is deployed before datasources are created through application.xml
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6099
> URL: https://issues.jboss.org/browse/WFLY-6099
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Renann Prado
> Assignee: Scott Marlow
> Attachments: server_with_mysql_driver.log
>
>
> Please refer to discussion
> https://developer.jboss.org/thread/267371
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months