Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-25478

[GSS](8.0.z) EJBCLIENT-512 - Client calling Clustered EJB fails after 2 invocations with an authentication issue when it tries to use the local-receiver

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 7.4.7.GA
    • EJB
    • False
    • None
    • False
    • Known Issue
    • Set a Value
    • Workaround Exists
    • Hide

      Using exclude-local-receiver="true" would workaround this, as it would never try a local-receiver in the jboss-ejb-client.xml in the app:

      <jboss-ejb-client xmlns="urn:jboss:ejb-client:1.0">
   <client-context>
      <ejb-receivers exclude-local-receiver="true">
   </client-context>
</jboss-ejb-client>
      Show
      Using exclude-local-receiver="true" would workaround this, as it would never try a local-receiver in the jboss-ejb-client.xml in the app: <jboss-ejb-client xmlns= "urn:jboss:ejb-client:1.0" > <client-context> <ejb-receivers exclude-local-receiver= " true " > </client-context> </jboss-ejb-client>

      Client calling Clustered EJB fails with authentication issue when it uses the local-receiver

      Setup:

      • EJB deployed on 2 nodes which are clustered
      • EJB is protected with @SecurityDomain, @RolesAllowed
      • Client looks up the EJB via new InitialContext(host/port/user/pass) where the host is either node1 or node2
        • it holds this reference
        • invokes methods on it several times
        • since the ejb is clustered, it will load balance and hit node1 and node2

      Behavior:

      The EJB invocation will succeed twice, when it is using a remote-receiver such as remote+http://127.0.0.1:8080 :

       DEBUG [org.jboss.ejb.client.invocation] (default task-1) sendRequest: setting receiver, strong affinity = Cluster "ejb", weak affinity = None, remote destination is: remote+http://127.0.0.1:8080
 

      ...

      But then it will switch and try to use the local-receiver to invoke the EJB when it is in the same JVM as the client, when this happens it has no identity so it ends up in this error:

      DEBUG [org.jboss.ejb.client.invocation] (default task-1) sendRequest: setting receiver, strong affinity = Cluster "ejb", weak affinity = None, remote destination is: local:- 
...
2022-10-07 15:49:07,047 ERROR [stderr] (default task-1) javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract org.jboss.as.quickstart.ejb.api.Response org.jboss.as.quickstart.ejb.api.StatelessRemote.invoke(org.jboss.as.quickstart.ejb.api.Request) of bean: StatelessEJB is not allowed
2022-10-07 15:49:07,047 ERROR [stderr] (default task-1)   at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:134)
2022-10-07 15:49:07,047 ERROR [stderr] (default task-1)   at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:45)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
2022-10-07 15:49:07,048 ERROR [stderr] (default task-1)   at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
2022-10-07 15:49:07,049 ERROR [stderr] (default task-1)   at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
2022-10-07 15:49:07,049 ERROR [stderr] (default task-1)   at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:633)

      Attaching debug logs

      • client-8080-logs.zip , this is when the client creates the InitialContext with localhost:8080 and client is on the same JVM localhost:8080
      • client-8180-logs.zip , this is when the client creates the InitialContext with localhost:8180 and client is on the same JVM localhost:8080

      Tests where client uses localhost:8180 in the initial contexts results in this when clicking invoke several times: server2, server1, fail with authorization exception

      When client uses localhost:8080, it results in : server1, server1, fail with authorization exception

      attachment jsf-ejb.war is a WAR file built from the attached reproducer and then transformed to jakarta api so that it can be deployed to WildFly 27+.

        3. jsf-ejb.war
          66 kB
          Petr Beran

              lvydra Lukas Vydra
              pberan@redhat.com Petr Beran
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: