Issue calling EJB over HTTP behind AWS load balancer

[jasi...@gmail.com]

I have a POJO Java client that needs to call an EJB running in WildFly 22 (standalone mode). WildFly is running behind an AWS load balancer.

Everything is fine if I have only one copy of the EJB service running behind the load balancer, but it falls apart when I add a second copy. The issue appears to be that the client does not include the authorization header on the initial request. The initial request goes through the load balancer to EJB copy A. EJB copy A responds that authentication is required

[io.undertow.request] (default I/O-8) Matched prefix path /wildfly-services for path /wildfly-services/ejb/v1/invoke/...

[io.undertow.request.security] (default I/O-8) Setting authentication required for exchange HttpServerExchange{ POST /wildfly-services/ejb/v1/invoke/...

The client then goes back through the load balancer to resend the request with the JSESSIONID cookie and the authorization header. Since the load balancer round-robins between services connected to it, this response hits EJB copy B instead of A, and EJB copy B doesn't have a clue what to do with it. The client ends up in an endless loop trying to authenticate with the server.

Is there a way to configure the client to force it to send the authorization header with the initial request?

Thanks!

[dt pham]

You may try to turn on the sticky session on the LB. Let it does LB by sessions, not by requests 

[jasi...@gmail.com]

I tried it, but it doesn't work. As far as I can tell the WildFly HTTP client does not process any cookies other than JSESSIONID. The stickiness cookie generated by the load balancer is just discarded.

[jasi...@gmail.com]

Just to tie this off...

I originally thought the issue was with a POJO client calling to a WildFly 22 server. That is not correct - the same issue exists when calling between two WildFly 22 standalone servers.

The problem appears to be related to stateful session beans. I've had no issues calling stateless EJBs, but one of our services uses stateful EJBs and those consitently fail when there are mutliple copies of the service behind an AWS classic load balancer.

I modifiied org.wildfly.httpclient.common.HttpTargetContext to treat the AWSELBCORS cookie exactly the same way it treats the JSESSIONID cookie. That resolves the problem.