[
https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin...
]
Richard Achmatowicz commented on WFLY-11489:
--------------------------------------------
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)