Spring-cloud-netflix: Zuul SockJS xhr_streaming failing, because heartbeat doesn't reach client

[iNaD]

Hi,

I already posted this question on Stackoverflow on May 31, but didn't receive any answer, so I decided to create an Issue in hope you can help me.

What I expect Zuul to do

Keep a xhr_streaming connection alive and receive the heartbeats of a SockJS server (also Spring based) as well as forwarding those heartbeats to the client.

What Zuul does

Connection opens, is kept open (already increased timeouts etc.), but client doesn't receive any heartbeats. Enabling Trace logging for Zuul didn't show anything suspicious but the new connection when the client timed out.

Setup

• Spring Boot - 1.5.3
• Spring Cloud Netflix - 1.3.1
• Nginx - 1.11
• RabbitMQ - 3.6.9

The client (in this case a simple Node script, could be replaced by a browser) --> Nginx as proxy for subdomain routing --> Zuul as Gateway --> @EnableWebSocketMessageBroker as Stomp relay --> RabbitMQ

How I tested it

I wrote a simple node script to test websockets (or better said, xhr_streaming, polling etc., because Zuul currently doesn't support real websockets), same packages are used in our Browser based application: Gist

So the results without Zuul look fine when logging, but with Zuul between the client and the stomp server it looks like this.

The Zuul Gateway itself is just a simple Spring Boot application with the annotations @SpringBootApplication, @EnableZuulProxy and @EnableResourceServer with this configuration.

So in conclusion, it is working fine (Websockets always disabled, because we won't use them anyway until Zuul supports it) without Nginx, with Nginx, but not with Zuul in between the client and the stomp relay.

[ryanjbaxter]

@iNaD thanks for the detailed information. Could you perhaps create a github repo with some sample apps that reproduces the problem?

[spencergibb]

Zuul doesn't support websockets

[spencergibb]

Or anything with long lived connections

[iNaD]

@ryanjbaxter I will try to reproduce this in a simple project.

@spencergibb like I already wrote, I know that Zuul doesn't support websockets, but to have a transition later on, SockJS seems to be the solution to go currently. The xhr_streaming is long lived, yes but even if it is killed by Zuul that shouldn't be a big problem if the heartbeats will reach the client in before. Then it will open a new connection and everything is fine.

[iNaD]

Ok a little update from my side.

Yes xhr_streaming doesn't work. On a simple project (just Zuul without any OAuth stuff etc. and a SimpleBrokerRelay as proxied service) SockJS is falling back to xhr_polling (better this than nothing).

In our real project SockJS seems to even fail to fallback to xhr_polling. So I suspect a dependency or another part in the architecture to be the cause.

Thanks anyway. I will close this issue for now, until I figured out why the polling won't work and open a new issue if it's Zuul related.

[ExtremeYu]

@spencergibb Zuul doesn't support websockets,but anyway to let zuul support that?

[ryanjbaxter]

No. Please dont ask your question on multiple issues.