[JBoss JIRA] (WFLY-10754) NullPointerException using Stateless with configured interceptors
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/WFLY-10754?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-10754:
--------------------------------------
Alright, glad it helped.
We should still identify what's the cause though, but I will lower the priority for now.
> NullPointerException using Stateless with configured interceptors
> -----------------------------------------------------------------
>
> Key: WFLY-10754
> URL: https://issues.jboss.org/browse/WFLY-10754
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: WildFly 13.0.0.Final and java 10.0.1
> Reporter: Luca Stancapiano
> Assignee: Matej Novotny
>
> I report a strange behavior on WildFly 13 when configuring interceptors within stateless. Below I describe the scenario:
> Here a simple interceptor:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.interceptor.AroundInvoke;
> import javax.interceptor.Interceptor;
> import javax.interceptor.InvocationContext;
> @Interceptor
> public class OKInterceptor {
> @AroundInvoke
> public Object aroundInvoke(InvocationContext ic) throws Exception {
> return ic.proceed();
> }
> }
> {code}
> Here an annotation used as interceptor binding:
> {code:java}
> package it.vige.injection.interceptors;
> import static java.lang.annotation.ElementType.CONSTRUCTOR;
> import static java.lang.annotation.ElementType.METHOD;
> import static java.lang.annotation.ElementType.TYPE;
> import static java.lang.annotation.RetentionPolicy.RUNTIME;
> import java.lang.annotation.Retention;
> import java.lang.annotation.Target;
> import javax.interceptor.InterceptorBinding;
> @Retention(RUNTIME)
> @Target({ METHOD, TYPE, CONSTRUCTOR })
> @InterceptorBinding
> public @interface NotOK {
> }
> {code}
> Here an interceptor annotated with the interceptor binding:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.interceptor.AroundInvoke;
> import javax.interceptor.Interceptor;
> import javax.interceptor.InvocationContext;
> @Interceptor
> @NotOK
> public class NotOKInterceptor {
> @AroundInvoke
> public Object aroundInvoke(InvocationContext ic) throws Exception {
> return ic.proceed();
> }
> }
> {code}
> Here the stateless service configured with both the interceptors:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.ejb.Stateless;
> import javax.interceptor.Interceptors;
> @Stateless
> public class SimpleService {
> @Interceptors({ OKInterceptor.class })
> public void ok() {
> }
> @NotOK
> public void notOk() {
> }
> }
> {code}
> This service must have two methods, one attached to the simple interceptor and the other attached to the interceptor binding.
> Here the beans.xml configuration:
> {code:java}
> <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
> version="2.0" bean-discovery-mode="all">
> <interceptors>
> <class>it.vige.injection.interceptors.OKInterceptor</class>
> <class>it.vige.injection.interceptors.NotOKInterceptor</class>
> </interceptors>
> </beans>
> {code}
> And in the end the client who call the service:
> {code:java}
> ....
> @Inject
> private SimpleService simpleService;
> ...
> // this call works:
> simpleService.ok();
> // this call starts a NullPointerException:
> simpleService.notOk();
> ...
> {code}
> when I try to call the notOk method I get this exception:
> {code:java}
> javax.ejb.EJBException: java.lang.NullPointerException
> at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
> Caused by: java.lang.NullPointerException
> at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
> {code}
> The same thing was tested on WildFly 12.0.0.Final and it was ok.
> If on WildFfly 13.0.0.Final I remove the @Stateless annotation from the service it works
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-6224) IllegalStateException "not in a valid state to be invoking cache operations on" in two cluster test
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6224?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6224:
-------------------------------------------
(text copied from WFLY-10607)
I'm looking at this issue at the moment. The issue centers around the operation of the StatefulComponentInstanceInterceptor and the StatefulSessionSynchronizationInterceptor which work together to manage the following: when a method invocation is processed at the server, lookup bean instances from the cache and attach them to the invocation, release those bean instances back to the cache when the invocation has finished, and manage registration of transaction synchronizations if the method is in the scope of a container-managed transaction. Actually, a lot more goes on, but its not worth going into in detail. For example, over and above the managed transaction, we have an Infinispan transaction associated with operations get()/put() on the cache which involve the InfinispanBatcher.
The "not in valid state" issue arises when the forwarding node tries to make an invocation on a remote bean and the bean is not found (i.e. NoSuchEJBException is returned as a result of the invocation). What happens here is this: the synchronization interceptor unconditionally calls release() in its finally clause to decrement the usage count of the bean instance which was looked up by the instance interceptor. Under the right conditions, this will case a commit of the Infinispan transaction. Later on, the instance interceptor handles the NoSuchEJBException on the method return by attempting to call discard() on the same bean instance within the same Infinispan transaction ; this fails because the Infinispan transaction has already been committed by the synchronization interceptor.
The fix here is to modify the code in the synchronization interceptor to check if the method invocation return is an exception and if so, do not call release() in that case - we don't want to commit work that is associated with (bad) exceptions. When this is done, the instance interceptor can now successfully call discard() and the problem is resolved.
> IllegalStateException "not in a valid state to be invoking cache operations on" in two cluster 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, 11.0.0.CR1, 13.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
>
> 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.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10754) NullPointerException using Stateless with configured interceptors
by Luca Stancapiano (JIRA)
[ https://issues.jboss.org/browse/WFLY-10754?page=com.atlassian.jira.plugin... ]
Luca Stancapiano commented on WFLY-10754:
-----------------------------------------
ok. Removing only the OKInterceptor from the beans.xml, both the interceptors are called, so it's ok for me. Thanks you
> NullPointerException using Stateless with configured interceptors
> -----------------------------------------------------------------
>
> Key: WFLY-10754
> URL: https://issues.jboss.org/browse/WFLY-10754
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: WildFly 13.0.0.Final and java 10.0.1
> Reporter: Luca Stancapiano
> Assignee: Matej Novotny
>
> I report a strange behavior on WildFly 13 when configuring interceptors within stateless. Below I describe the scenario:
> Here a simple interceptor:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.interceptor.AroundInvoke;
> import javax.interceptor.Interceptor;
> import javax.interceptor.InvocationContext;
> @Interceptor
> public class OKInterceptor {
> @AroundInvoke
> public Object aroundInvoke(InvocationContext ic) throws Exception {
> return ic.proceed();
> }
> }
> {code}
> Here an annotation used as interceptor binding:
> {code:java}
> package it.vige.injection.interceptors;
> import static java.lang.annotation.ElementType.CONSTRUCTOR;
> import static java.lang.annotation.ElementType.METHOD;
> import static java.lang.annotation.ElementType.TYPE;
> import static java.lang.annotation.RetentionPolicy.RUNTIME;
> import java.lang.annotation.Retention;
> import java.lang.annotation.Target;
> import javax.interceptor.InterceptorBinding;
> @Retention(RUNTIME)
> @Target({ METHOD, TYPE, CONSTRUCTOR })
> @InterceptorBinding
> public @interface NotOK {
> }
> {code}
> Here an interceptor annotated with the interceptor binding:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.interceptor.AroundInvoke;
> import javax.interceptor.Interceptor;
> import javax.interceptor.InvocationContext;
> @Interceptor
> @NotOK
> public class NotOKInterceptor {
> @AroundInvoke
> public Object aroundInvoke(InvocationContext ic) throws Exception {
> return ic.proceed();
> }
> }
> {code}
> Here the stateless service configured with both the interceptors:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.ejb.Stateless;
> import javax.interceptor.Interceptors;
> @Stateless
> public class SimpleService {
> @Interceptors({ OKInterceptor.class })
> public void ok() {
> }
> @NotOK
> public void notOk() {
> }
> }
> {code}
> This service must have two methods, one attached to the simple interceptor and the other attached to the interceptor binding.
> Here the beans.xml configuration:
> {code:java}
> <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
> version="2.0" bean-discovery-mode="all">
> <interceptors>
> <class>it.vige.injection.interceptors.OKInterceptor</class>
> <class>it.vige.injection.interceptors.NotOKInterceptor</class>
> </interceptors>
> </beans>
> {code}
> And in the end the client who call the service:
> {code:java}
> ....
> @Inject
> private SimpleService simpleService;
> ...
> // this call works:
> simpleService.ok();
> // this call starts a NullPointerException:
> simpleService.notOk();
> ...
> {code}
> when I try to call the notOk method I get this exception:
> {code:java}
> javax.ejb.EJBException: java.lang.NullPointerException
> at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
> Caused by: java.lang.NullPointerException
> at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
> {code}
> The same thing was tested on WildFly 12.0.0.Final and it was ok.
> If on WildFfly 13.0.0.Final I remove the @Stateless annotation from the service it works
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-6224) IllegalStateException "not in a valid state to be invoking cache operations on" in two cluster test
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6224?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated WFLY-6224:
--------------------------------------
Affects Version/s: 13.0.0.Final
> IllegalStateException "not in a valid state to be invoking cache operations on" in two cluster 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, 11.0.0.CR1, 13.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Paul Ferraro
>
> 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.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10756) ISPN000136: Error executing command LockControlCommand
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-10756?page=com.atlassian.jira.plugin... ]
tommaso borgato updated WFLY-10756:
-----------------------------------
Description:
The error was observed in scenario {{*[eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering_JJB/view/clustering-ejb-ejbservlet-tests/job/eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync_JJB/4/]*}}: a 4 nodes cluster with a mod_jk load balancer where fail-over is introduced by killing the node jvm.
The error was observed on node {{*[perf19|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering_JJB/view/clustering-ejb-ejbservlet-tests/job/eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync_JJB/4/console-perf19/]*}} right after it was re-started (the server jvm was previously killed to introduce fail-over):
{noformat}
[JBossINF] [0m[0m02:43:51,746 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 14.0.0.Beta2-SNAPSHOT (WildFly Core 6.0.0.Alpha4) started in 12738ms - Started 973 of 1160 services (477 services are lazy, passive or on-demand)
[JBossINF] [0m[0m02:44:37,268 INFO [org.jboss.ejb.client] (default task-1) JBoss EJB Client version 4.0.11.Final
[JBossINF] [0m[0m02:44:56,928 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
[JBossINF] [0m[0m02:44:56,942 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
[JBossINF] [0m[0m02:44:56,948 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
[JBossINF] [0m[0m02:44:56,949 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
[JBossINF] [0m[0m02:44:56,949 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
[JBossINF] [0m[0m02:44:56,950 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
[JBossINF] [0m[0m02:44:56,955 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
[JBossINF] [0m[0m02:44:56,978 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
[JBossINF] [0m[0m02:45:58,220 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
[JBossINF] [0m[0m02:45:58,221 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
[JBossINF] [0m[0m02:45:58,223 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
[JBossINF] [0m[0m02:45:58,223 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
[JBossINF] [0m[0m02:45:58,224 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
[JBossINF] [0m[0m02:45:58,225 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
[JBossINF] [0m[0m02:45:58,225 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
[JBossINF] [0m[0m02:45:58,226 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
[JBossINF] [0m[0m02:47:11,387 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
[JBossINF] [0m[0m02:47:11,389 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
[JBossINF] [0m[0m02:47:11,390 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
[JBossINF] [0m[0m02:47:11,390 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
[JBossINF] [0m[0m02:47:11,392 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
[JBossINF] [0m[0m02:47:11,393 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
[JBossINF] [0m[0m02:47:11,393 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
[JBossINF] [0m[0m02:47:11,394 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
[JBossINF] [0m[31m02:47:12,082 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (remote-thread--p8-t60) ISPN000136: Error executing command LockControlCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 0 milliseconds for key SessionCreationMetaDataKey(2UakcseFRb1cI_zcOL5fwpJnkR8j-fo74TsVeNSo) and requestor GlobalTx:perf20:25537. Lock is held by GlobalTx:perf19:118742
[JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.get(DefaultLockManager.java:288)
[JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:261)
[JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:209)
[JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:46)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:81)
[JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:192)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:183)
[JBossINF] at org.infinispan.interceptors.impl.TxInterceptor.visitLockControlCommand(TxInterceptor.java:222)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.lambda$new$0(BaseAsyncInterceptor.java:22)
[JBossINF] at org.infinispan.interceptors.InvocationSuccessFunction.apply(InvocationSuccessFunction.java:25)
[JBossINF] at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:70)
[JBossINF] at org.infinispan.interceptors.InvocationStage.thenApply(InvocationStage.java:45)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.asyncInvokeNext(BaseAsyncInterceptor.java:224)
[JBossINF] at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:46)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:185)
[JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:90)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123)
[JBossINF] at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56)
[JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
[JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.visitLockControlCommand(DDAsyncInterceptor.java:160)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
[JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
[JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.invokeAsync(LockControlCommand.java:126)
[JBossINF] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:94)
[JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99)
[JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71)
[JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[JBossINF] at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
[JBossINF] at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
The error was observed in scenario {{*[eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering_JJB/view/clustering-ejb-ejbservlet-tests/job/eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync_JJB/4/]*}}: a 4 nodes cluster with a mod_jk load balancer where fail-over is introduced by killing the node jvm.
The error was observed on node {{*[perf19|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering_JJB/view/clustering-ejb-ejbservlet-tests/job/eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync_JJB/4/console-perf19/]*}} right after it was re-started after being killed:
{noformat}
[JBossINF] [0m[0m02:43:51,746 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 14.0.0.Beta2-SNAPSHOT (WildFly Core 6.0.0.Alpha4) started in 12738ms - Started 973 of 1160 services (477 services are lazy, passive or on-demand)
[JBossINF] [0m[0m02:44:37,268 INFO [org.jboss.ejb.client] (default task-1) JBoss EJB Client version 4.0.11.Final
[JBossINF] [0m[0m02:44:56,928 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
[JBossINF] [0m[0m02:44:56,942 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
[JBossINF] [0m[0m02:44:56,948 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
[JBossINF] [0m[0m02:44:56,949 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
[JBossINF] [0m[0m02:44:56,949 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
[JBossINF] [0m[0m02:44:56,950 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
[JBossINF] [0m[0m02:44:56,955 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
[JBossINF] [0m[0m02:44:56,978 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
[JBossINF] [0m[0m02:45:58,220 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
[JBossINF] [0m[0m02:45:58,221 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
[JBossINF] [0m[0m02:45:58,223 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
[JBossINF] [0m[0m02:45:58,223 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
[JBossINF] [0m[0m02:45:58,224 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
[JBossINF] [0m[0m02:45:58,225 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
[JBossINF] [0m[0m02:45:58,225 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
[JBossINF] [0m[0m02:45:58,226 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
[JBossINF] [0m[0m02:47:11,387 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
[JBossINF] [0m[0m02:47:11,389 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
[JBossINF] [0m[0m02:47:11,390 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
[JBossINF] [0m[0m02:47:11,390 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
[JBossINF] [0m[0m02:47:11,392 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
[JBossINF] [0m[0m02:47:11,393 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
[JBossINF] [0m[0m02:47:11,393 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
[JBossINF] [0m[0m02:47:11,394 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
[JBossINF] [0m[31m02:47:12,082 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (remote-thread--p8-t60) ISPN000136: Error executing command LockControlCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 0 milliseconds for key SessionCreationMetaDataKey(2UakcseFRb1cI_zcOL5fwpJnkR8j-fo74TsVeNSo) and requestor GlobalTx:perf20:25537. Lock is held by GlobalTx:perf19:118742
[JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.get(DefaultLockManager.java:288)
[JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:261)
[JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:209)
[JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:46)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:81)
[JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:192)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:183)
[JBossINF] at org.infinispan.interceptors.impl.TxInterceptor.visitLockControlCommand(TxInterceptor.java:222)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.lambda$new$0(BaseAsyncInterceptor.java:22)
[JBossINF] at org.infinispan.interceptors.InvocationSuccessFunction.apply(InvocationSuccessFunction.java:25)
[JBossINF] at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:70)
[JBossINF] at org.infinispan.interceptors.InvocationStage.thenApply(InvocationStage.java:45)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.asyncInvokeNext(BaseAsyncInterceptor.java:224)
[JBossINF] at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:46)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:185)
[JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:90)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123)
[JBossINF] at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90)
[JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56)
[JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
[JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.visitLockControlCommand(DDAsyncInterceptor.java:160)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
[JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
[JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234)
[JBossINF] at org.infinispan.commands.control.LockControlCommand.invokeAsync(LockControlCommand.java:126)
[JBossINF] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:94)
[JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99)
[JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71)
[JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[JBossINF] at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
[JBossINF] at java.lang.Thread.run(Thread.java:748)
{noformat}
> ISPN000136: Error executing command LockControlCommand
> -------------------------------------------------------
>
> Key: WFLY-10756
> URL: https://issues.jboss.org/browse/WFLY-10756
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.CR1
> Reporter: tommaso borgato
> Assignee: Paul Ferraro
>
> The error was observed in scenario {{*[eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering_JJB/view/clustering-ejb-ejbservlet-tests/job/eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync_JJB/4/]*}}: a 4 nodes cluster with a mod_jk load balancer where fail-over is introduced by killing the node jvm.
> The error was observed on node {{*[perf19|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Clustering_JJB/view/clustering-ejb-ejbservlet-tests/job/eap-7x-failover-ejb-ejbservlet-jvmkill-dist-sync_JJB/4/console-perf19/]*}} right after it was re-started (the server jvm was previously killed to introduce fail-over):
> {noformat}
> [JBossINF] [0m[0m02:43:51,746 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 14.0.0.Beta2-SNAPSHOT (WildFly Core 6.0.0.Alpha4) started in 12738ms - Started 973 of 1160 services (477 services are lazy, passive or on-demand)
> [JBossINF] [0m[0m02:44:37,268 INFO [org.jboss.ejb.client] (default task-1) JBoss EJB Client version 4.0.11.Final
> [JBossINF] [0m[0m02:44:56,928 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
> [JBossINF] [0m[0m02:44:56,942 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
> [JBossINF] [0m[0m02:44:56,948 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
> [JBossINF] [0m[0m02:44:56,949 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
> [JBossINF] [0m[0m02:44:56,949 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
> [JBossINF] [0m[0m02:44:56,950 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
> [JBossINF] [0m[0m02:44:56,955 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|8] (3) [perf21, perf18, perf19]
> [JBossINF] [0m[0m02:44:56,978 INFO [org.infinispan.CLUSTER] (thread-65,ejb,perf19) ISPN100001: Node perf20 left the cluster
> [JBossINF] [0m[0m02:45:58,220 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
> [JBossINF] [0m[0m02:45:58,221 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
> [JBossINF] [0m[0m02:45:58,223 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
> [JBossINF] [0m[0m02:45:58,223 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
> [JBossINF] [0m[0m02:45:58,224 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
> [JBossINF] [0m[0m02:45:58,225 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
> [JBossINF] [0m[0m02:45:58,225 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf21|9] (4) [perf21, perf18, perf19, perf20]
> [JBossINF] [0m[0m02:45:58,226 INFO [org.infinispan.CLUSTER] (thread-71,ejb,perf19) ISPN100000: Node perf20 joined the cluster
> [JBossINF] [0m[0m02:47:11,387 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
> [JBossINF] [0m[0m02:47:11,389 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
> [JBossINF] [0m[0m02:47:11,390 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
> [JBossINF] [0m[0m02:47:11,390 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
> [JBossINF] [0m[0m02:47:11,392 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
> [JBossINF] [0m[0m02:47:11,393 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
> [JBossINF] [0m[0m02:47:11,393 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN000094: Received new cluster view for channel ejb: [perf18|10] (3) [perf18, perf19, perf20]
> [JBossINF] [0m[0m02:47:11,394 INFO [org.infinispan.CLUSTER] (thread-87,ejb,perf19) ISPN100001: Node perf21 left the cluster
> [JBossINF] [0m[31m02:47:12,082 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (remote-thread--p8-t60) ISPN000136: Error executing command LockControlCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 0 milliseconds for key SessionCreationMetaDataKey(2UakcseFRb1cI_zcOL5fwpJnkR8j-fo74TsVeNSo) and requestor GlobalTx:perf20:25537. Lock is held by GlobalTx:perf19:118742
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.get(DefaultLockManager.java:288)
> [JBossINF] at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:261)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:209)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:46)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:81)
> [JBossINF] at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:192)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:183)
> [JBossINF] at org.infinispan.interceptors.impl.TxInterceptor.visitLockControlCommand(TxInterceptor.java:222)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.lambda$new$0(BaseAsyncInterceptor.java:22)
> [JBossINF] at org.infinispan.interceptors.InvocationSuccessFunction.apply(InvocationSuccessFunction.java:25)
> [JBossINF] at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:70)
> [JBossINF] at org.infinispan.interceptors.InvocationStage.thenApply(InvocationStage.java:45)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.asyncInvokeNext(BaseAsyncInterceptor.java:224)
> [JBossINF] at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:46)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:185)
> [JBossINF] at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:90)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123)
> [JBossINF] at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90)
> [JBossINF] at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56)
> [JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> [JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.visitLockControlCommand(DDAsyncInterceptor.java:160)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> [JBossINF] at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
> [JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.invokeAsync(LockControlCommand.java:126)
> [JBossINF] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:94)
> [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99)
> [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71)
> [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFLY-10754) NullPointerException using Stateless with configured interceptors
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/WFLY-10754?page=com.atlassian.jira.plugin... ]
Matej Novotny commented on WFLY-10754:
--------------------------------------
[~sviluppatorefico] you need to remove *only* {{OKInterceptor}}.
E.g. your {{beans.xml}} will look like [this|https://gist.github.com/manovotn/05ba58da8c3d84b60cc55862edd68704].
> NullPointerException using Stateless with configured interceptors
> -----------------------------------------------------------------
>
> Key: WFLY-10754
> URL: https://issues.jboss.org/browse/WFLY-10754
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 13.0.0.Final
> Environment: WildFly 13.0.0.Final and java 10.0.1
> Reporter: Luca Stancapiano
> Assignee: Matej Novotny
>
> I report a strange behavior on WildFly 13 when configuring interceptors within stateless. Below I describe the scenario:
> Here a simple interceptor:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.interceptor.AroundInvoke;
> import javax.interceptor.Interceptor;
> import javax.interceptor.InvocationContext;
> @Interceptor
> public class OKInterceptor {
> @AroundInvoke
> public Object aroundInvoke(InvocationContext ic) throws Exception {
> return ic.proceed();
> }
> }
> {code}
> Here an annotation used as interceptor binding:
> {code:java}
> package it.vige.injection.interceptors;
> import static java.lang.annotation.ElementType.CONSTRUCTOR;
> import static java.lang.annotation.ElementType.METHOD;
> import static java.lang.annotation.ElementType.TYPE;
> import static java.lang.annotation.RetentionPolicy.RUNTIME;
> import java.lang.annotation.Retention;
> import java.lang.annotation.Target;
> import javax.interceptor.InterceptorBinding;
> @Retention(RUNTIME)
> @Target({ METHOD, TYPE, CONSTRUCTOR })
> @InterceptorBinding
> public @interface NotOK {
> }
> {code}
> Here an interceptor annotated with the interceptor binding:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.interceptor.AroundInvoke;
> import javax.interceptor.Interceptor;
> import javax.interceptor.InvocationContext;
> @Interceptor
> @NotOK
> public class NotOKInterceptor {
> @AroundInvoke
> public Object aroundInvoke(InvocationContext ic) throws Exception {
> return ic.proceed();
> }
> }
> {code}
> Here the stateless service configured with both the interceptors:
> {code:java}
> package it.vige.injection.interceptors;
> import javax.ejb.Stateless;
> import javax.interceptor.Interceptors;
> @Stateless
> public class SimpleService {
> @Interceptors({ OKInterceptor.class })
> public void ok() {
> }
> @NotOK
> public void notOk() {
> }
> }
> {code}
> This service must have two methods, one attached to the simple interceptor and the other attached to the interceptor binding.
> Here the beans.xml configuration:
> {code:java}
> <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/beans_2_0.xsd"
> version="2.0" bean-discovery-mode="all">
> <interceptors>
> <class>it.vige.injection.interceptors.OKInterceptor</class>
> <class>it.vige.injection.interceptors.NotOKInterceptor</class>
> </interceptors>
> </beans>
> {code}
> And in the end the client who call the service:
> {code:java}
> ....
> @Inject
> private SimpleService simpleService;
> ...
> // this call works:
> simpleService.ok();
> // this call starts a NullPointerException:
> simpleService.notOk();
> ...
> {code}
> when I try to call the notOk method I get this exception:
> {code:java}
> javax.ejb.EJBException: java.lang.NullPointerException
> at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
> Caused by: java.lang.NullPointerException
> at deployment.test.war//it.vige.injection.test.InterceptorsTestCase.testNotOk(InterceptorsTestCase.java:52)
> {code}
> The same thing was tested on WildFly 12.0.0.Final and it was ok.
> If on WildFfly 13.0.0.Final I remove the @Stateless annotation from the service it works
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months