[JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin... ]
Tomas Hofman commented on JBJCA-1338:
-------------------------------------
PR with a suggested solution.
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1338
> URL: https://issues.jboss.org/browse/JBJCA-1338
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.2.7.Final
> Reporter: Tomas Hofman
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (JBJCA-1338) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1338?page=com.atlassian.jira.plugin... ]
Tomas Hofman reassigned JBJCA-1338:
-----------------------------------
Assignee: Tomas Hofman
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1338
> URL: https://issues.jboss.org/browse/JBJCA-1338
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 1.2.7.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8041) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by Tomas Hofman (JIRA)
Tomas Hofman created WFLY-8041:
----------------------------------
Summary: CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
Key: WFLY-8041
URL: https://issues.jboss.org/browse/WFLY-8041
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 10.1.0.Final
Reporter: Tomas Hofman
Assignee: Stefano Maestri
PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
The scenario is as follows:
# A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
# 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
# The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
# The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
# 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7104) Elytron properties-realm enforces REALM_NAME comment
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7104?page=com.atlassian.jira.plugin.... ]
Josef Cacek updated WFLY-7104:
------------------------------
Steps to Reproduce:
{code}
touch /tmp/users.properties
bin/jboss-cli.sh -c "/subsystem=elytron/properties-realm=test:add(users-properties={path=/tmp/users.properties, plain-text=true})"
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.test" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in users property file - file must contain \"#$REALM_NAME=RealmName$\" line"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.test"]
},
"rolled-back" => true
}
{code}
Server log contains then:
{code}
07:00:27,993 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service org.wildfly.security.security-realm.test: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in users property file - file must contain "#$REALM_NAME=RealmName$" line
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:194)
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:172)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
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)
07:00:27,998 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("properties-realm" => "test")
]) - failure description: {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.test" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00025: Referenced property file is invalid: ELY01006: No realm name found in users property file - file must contain \"#$REALM_NAME=RealmName$\" line"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.test"]
}
07:00:28,009 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report
WFLYCTL0186: Services which failed to start: service org.wildfly.security.security-realm.test
{code}
was:
{code}
touch /tmp/users.properties
bin/jboss-cli.sh -c "/subsystem=elytron/properties-realm=test:add(users-properties={path=/tmp/users.properties}, plain-text=true)"
{
"outcome" => "failed",
"failure-description" => {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.test" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00014: Unable to load the properties files required to start the properties file backed realm.
Caused by: java.io.IOException: ELY01006: No realm name found in properties file"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.test"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
},
"rolled-back" => true
}
{code}
Server log contains then:
{code}
13:09:20,521 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.security-realm.test: org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00014: Unable to load the properties files required to start the properties file backed realm.
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:181)
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:162)
at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
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)
Caused by: java.io.IOException: ELY01006: No realm name found in properties file
at org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm.load(LegacyPropertiesSecurityRealm.java:260)
at org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm$Builder.build(LegacyPropertiesSecurityRealm.java:335)
at org.wildfly.extension.elytron.PropertiesRealmDefinition$1$1.get(PropertiesRealmDefinition.java:178)
... 7 more
13:09:20,522 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 5) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "elytron"),
("properties-realm" => "test")
]) - failure description: {
"WFLYCTL0080: Failed services" => {"org.wildfly.security.security-realm.test" => "org.jboss.msc.service.StartException in service org.wildfly.security.security-realm.test: WFLYELY00014: Unable to load the properties files required to start the properties file backed realm.
Caused by: java.io.IOException: ELY01006: No realm name found in properties file"},
"WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.test"],
"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
}
13:09:20,528 INFO [org.jboss.as.controller] (management-handler-thread - 5) WFLYCTL0183: Service status report
WFLYCTL0186: Services which failed to start: service org.wildfly.security.security-realm.test
{code}
> Elytron properties-realm enforces REALM_NAME comment
> ----------------------------------------------------
>
> Key: WFLY-7104
> URL: https://issues.jboss.org/browse/WFLY-7104
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> Elytron enforces existence of {{"#$REALM_NAME=...$"}} comment in property file referenced from properties-realms.
> When using legacy security and this line is missing, server starts without error.
> *Expected behavior:*
> Elytron's properties-realm *doesn't require* this comment. If the comment is present, it *may* verify if its content fits the realm name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-7104) Elytron properties-realm enforces REALM_NAME comment
by Josef Cacek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7104?page=com.atlassian.jira.plugin.... ]
Josef Cacek reopened WFLY-7104:
-------------------------------
Reopening. The issue is still valid.
> Elytron properties-realm enforces REALM_NAME comment
> ----------------------------------------------------
>
> Key: WFLY-7104
> URL: https://issues.jboss.org/browse/WFLY-7104
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> Elytron enforces existence of {{"#$REALM_NAME=...$"}} comment in property file referenced from properties-realms.
> When using legacy security and this line is missing, server starts without error.
> *Expected behavior:*
> Elytron's properties-realm *doesn't require* this comment. If the comment is present, it *may* verify if its content fits the realm name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8040) Infinispan subsystem registers duplicate capabilities when using ha profiles
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-8040:
----------------------------------
Summary: Infinispan subsystem registers duplicate capabilities when using ha profiles
Key: WFLY-8040
URL: https://issues.jboss.org/browse/WFLY-8040
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The Infinispan subsystem registers capabilities for local implementations of the clustering API. When the JGroups subsystem is *not* installed, the Inifinispan subsystem is meant to register its local implementations as the default implementation. However, currently it is always registering them, causing duplicate capability registrations.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8039) Subsystem tests are registering the same capability in multiple spots; clean this up
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8039:
--------------------------------------
Summary: Subsystem tests are registering the same capability in multiple spots; clean this up
Key: WFLY-8039
URL: https://issues.jboss.org/browse/WFLY-8039
Project: WildFly
Issue Type: Task
Components: Batch, EJB, JCA, Web (Undertow)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
A number of subsystem modules in their tests are registering the same capability in more than one place. This is incorrect behavior and WFCORE-2270 will reject it. This task is to clean this up so WFCORE-2270 can progress.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8038) Subsystem tests are registering the same capability in multiple spots; clean this up
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-8038:
--------------------------------------
Summary: Subsystem tests are registering the same capability in multiple spots; clean this up
Key: WFLY-8038
URL: https://issues.jboss.org/browse/WFLY-8038
Project: WildFly
Issue Type: Task
Components: Batch, EJB, JCA, Web (Undertow)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
A number of subsystem modules in their tests are registering the same capability in more than one place. This is incorrect behavior and WFCORE-2270 will reject it. This task is to clean this up so WFCORE-2270 can progress.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFCORE-2270) Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2270:
----------------------------------------
Summary: Capability registry should not allow more than one registration point for a RuntimeCapabilityRegistration
Key: WFCORE-2270
URL: https://issues.jboss.org/browse/WFCORE-2270
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
CapabilityRegistry.registerCapability is allowing more than one registration point for the same RuntimeCapabilityRegistration. This is not correct. A *possible* capability can be registered from more than one location, and the user then chooses to configure one. An the same capability name can be configured at more than one address in a domain-wide config, so long as those addresses have different scopes. But within the same scope, the config can only have the same cap in one place.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-6224) IllegalStateException "transaction is not in a valid state" during a 2clusters test
by Lucas Ponce (JIRA)
[ https://issues.jboss.org/browse/WFLY-6224?page=com.atlassian.jira.plugin.... ]
Lucas Ponce commented on WFLY-6224:
-----------------------------------
I have also a similar issue in Hawkular:
{code}
2017-02-06 23:16:31,422 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-3) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=662}, status=1} is not in a valid state to be invoking cache operations on.
at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:405)
at org.infinispan.statetransfer.StateTransferInterceptor.handleDefault(StateTransferInterceptor.java:390)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
at org.hawkular.alerts.engine.impl.PartitionManagerImpl.notifyTrigger(PartitionManagerImpl.java:276)
{code}
I see the bug is still open and target is 1.2.0.Final.
Is there any workaround available that can be applied on 1.0.0.Final ?
> IllegalStateException "transaction is not in a valid state" during a 2clusters test
> -----------------------------------------------------------------------------------
>
> Key: WFLY-6224
> URL: https://issues.jboss.org/browse/WFLY-6224
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
> Fix For: 10.2.0.Final
>
>
> During a 2clusters test eap-7x-failover-ejb-2clusters-ejbremote-shutdown-repl-async (where 2clusters test = standalone EJB client -> 2-node "forwarder" cluster -> 2-node "target" cluster -> back to "forwarder" -> back to standalone client), I'm seeing {{IllegalStateException: Transaction is not in a valid state to be invoking cache operations on}}:
> {code}
> 05:12:09,813 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-40) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=352}, status=3} is not in a valid state to be invoking cache operations on.
> at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:394)
> at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:350)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:344)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:85)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
> at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:238)
> at org.jboss.as.ejb3.cache.distributable.DistributableCache.release(DistributableCache.java:137)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.releaseInstance(StatefulSessionSynchronizationInterceptor.java:168)
> at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization.afterCompletion(StatefulSessionSynchronizationInterceptor.java:250)
> at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.afterCompletion(JCAOrderedLastSynchronizationList.java:147)
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:545)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:476)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.SubordinateAtomicAction.doOnePhaseCommit(SubordinateAtomicAction.java:247)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple.doOnePhaseCommit(TransactionImple.java:283)
> at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionCommitTask.manageTransaction(XidTransactionCommitTask.java:85)
> at org.jboss.as.ejb3.remote.protocol.versionone.XidTransactionManagementTask.run(XidTransactionManagementTask.java:68)
> at org.jboss.as.ejb3.remote.protocol.versionone.TransactionRequestHandler.processMessage(TransactionRequestHandler.java:139)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:717)
> 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)
> {code}
> The difference from WFLY-4678 is the circumstances.
> In the following text, I'm refering to the nodes by their real names: {{perf17}} is the standalone EJB client, the "forwarder" cluster is {{perf20}} and {{perf21}}, and the "target" cluster is {{perf18}} and {{perf19}}.
> The stack trace above is the first occurence of the exception, it appears on perf19 (https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-...). At that time, perf18 is just shutting down gracefully, but the perf19 log clearly shows that both Infinispan and JGroups have already figured out that perf18 went away. Still, the absence of graceful shutdown for transactions might be an explanation... except that there's no reason why the cache on perf19 would be in an invalid state if it's perf18 who is going down. So maybe perf19 had to reach out to perf18 for some reason and the exception actually comes from perf18... but the cache is REPL, so perf19 should have all data locally already and it shouldn't really have to reach out to perf18.
> So, not really sure why it happens.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months