[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
4:53 a.m.
[
https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin...
]
Richard Achmatowicz edited comment on WFLY-11489 at 1/24/19 5:52 AM:
---------------------------------------------------------------------
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 and 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 sets the destination 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 as usual. Then TransactionPostDiscovery takes the discovered destination and
adds it to the applications map, which is obtains as an attachment to the invocation
context. That destination will be used for an invocation on the same module the next time
around. Additionally, Transaction also uses the application map to give hints to
Discovery: when Transaction cannot set the destination, it attaches its current list of
URIs from the applications map as PREFERRED_DESTINATIONS; Discovery will use this if it
has to choose one URI from several available. This means in practice that Transaction will
ask Discovery to choose nodes that Transaction has seen before.
Remoting just removes nodes from the discovered node registry (DNR) when a chosen
destination returns a NoSuchEJBException.
was (Author: rachmato):
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)
2729
days inactive
2729
days old
0 comments
1 participants
participants (1)
-
Richard Achmatowicz (Jira)