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

Tue Jan 22 11:22:00 EST 2019

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

Richard Achmatowicz edited comment on WFLY-11489 at 1/22/19 11:21 AM:
----------------------------------------------------------------------

I should also note that the changes I made to the EJB client caused a failure in the LearningTestCase. Fixing this error deepened by understanding of how this client works. I might as well explain it here; or at least i'll explain my understanding of it.

Learning is a feature related to proxies created from the same initial context. When we create a proxy for a SFSB, it has something called a baseAffinity, a strong affinity which restricts which nodes can be used for the initial invocation which creates the session. If learning is enabled, if we lookup a SFSB using an initial context, and it ends up having strong affinity tied to a cluster, then any proxies generated later by lookups on SFSBs from the same initial context will automatically inherit the same baseAffinity; in other words, they will be automatically tied to the same cluster. This feature can be disabled by including the property jboss.disable-affinity-learning = true in the InitialContext environment. The default value for baseAffinity is Affinity.NONE, which means the initial session creation invocation could be directed to any node. If we wish to specify the default baseAffinity (which must be of type ClusterAffinity), we can use the InitialContext property jboss.cluster-affinity = <cluster name>.

The problem in LearningTestCase was that  proxies for SFSBs were being created (which includes the session being created on the chosen server node) and returning with strong affinity = NONE, which is not what is supposed to happen: SFSBs should have strong affinity either to the node (if the chosen target for the initial session creation pointed to a standalone node) or a cluster(if the chosen target for the initial session creation pointed to a cluster node).

I adjusted the expected affinity from Affinity.NONE to URIAffinity(new URI("remote://localhost:6999)) which is the affinity that will result when passing through the NamingEJBClientInterceptor when a PROVIDER_URL is in the InitialContext environment. 

was (Author: rachmato):
I should also note that the changes I made to the EJB client caused a failure in the LearningTestCase. Fixing this error deepened by understanding of how this client works. I might as well explain it here; or at least i'll explain my understanding of it.

Learning is a feature related to proxies created from the same initial context. When we create a proxy for a SFSB, it has something called a baseAffinity, a strong affinity which restricts which nodes can be used for the initial invocation which creates the session. If learning is enabled, if we lookup a SFSB using an initial context, and it ends up having strong affinity tied to a cluster, then any proxies generated later by lookups on SFSBs from the same initial context will automatically inherit the same baseAffinity; in other words, they will be automatically tied to the same cluster. This feature can be disabled by including the property jboss.disable-affinity-learning = true in the InitialContext environment. The default value for baseAffinity is Affinity.NONE. If we wish to specify the default baseAffinity (which must be of type ClusterAffinity), we can use the InitialContext property jboss.cluster-affinity = <cluster name>.

The problem in LearningTestCase was that  proxies for SFSBs were being created (which includes the session being created on the chosen server node) and returning with strong affinity = NONE, which is not what is supposed to happen: SFSBs should have strong affinity either to the node (if the chosen target for the initial session creation pointed to a standalone node) or a cluster(if the chosen target for the initial session creation pointed to a cluster node).
I adjusted the expected affinity from Affinity.NONE to URIAffinity(new URI("remote://localhost:6999)) which is the affinity that will result when passing through the NamingEJBClientInterceptor when a PROVIDER_URL is in the InitialContext environment. 

> 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)