[jboss-jira] [JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled

[Richard Achmatowicz (Jira)]

    [ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686992#comment-13686992 ] 

Richard Achmatowicz commented on WFLY-11489:
--------------------------------------------

Just a note for future reference. There are five interceptors which get executed in this order:
TransactionInterceptor
NamingEJBClientInterceptor
DiscoveryEJBClientInterceptor
TransactionPostDiscoveryInterceptor
RemotingEJBClientInterceptor
Here is the way I look at these. 

Naming and Discovery find and set destinations for invocations. Naming does it based on a list of URLs in PROVIDER_URLs in the JNDI InitialContext which is used to lookup the EJB client proxy. Discovery does it based on configured connections in the EJBClientContext as well as dynamically discovered connections from clusters. Naming is only activated if (strong affinity, weak affinity) = (NONE, NONE). Discovery works for all affinity combinations. If one finds a destination, the other will let that selection stand (i.e. they don't interfere with each other).

Transaction and TransactionPostDiscovery work together to ensure transaction stickiness. They do not discover destinations and leave that up to naming an Discovery. Transaction holds an applications map which maps module names to destinations: if an invocation arrives for a module which Transaction has seen before, it sends it to the same node using the applications map. This map is a resource on the transaction so it dies when the transaction is committed. If Transaction does not recognize the invocation module, it attaches the map to the invocation context. Discovery is carried out by naming or Discovery. Then TransactionPostDiscovery  takes the discovered destination and adds it to the applications map, which is obtains as an attachment to the invocation context.

Remoting just removes nodes from the discovered node registry (DNR) when a chosen destination returns a NoSuchEJBException.
 


> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-11489
>                 URL: https://issues.jboss.org/browse/WFLY-11489
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Remoting
>    Affects Versions: 15.0.0.Final
>         Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
>            Reporter: Jörg Bäsner
>            Assignee: Richard Achmatowicz
>            Priority: Major
>         Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> 	at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> 	at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> 	at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> 	at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> 	at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> 	at java.lang.Thread.run(Thread.java:748)
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)