Problems with persistent connection only in "production"

[Former Member]

Hi,

Background

I've been working with a proof of concept in which I utilize persistent connection between a client (Javascript and sapui5) and a server (on #SAPNWCLoud).

This allows me to broadcast server side events to all connected clients.

I'm using the atmosphere framework https://github.com/Atmosphere/atmosphere which is great for this purpose.

Since the tomcat web server on #SAPNWCloud doesn't yet support web sockets, I am using a mode called SSE (server side events) For more information on SSE, see http://jfarcand.wordpress.com/2012/05/14/writing-portable-html5-server-side-evens-application-using-... .

Problem

The solution works well on the local development environment, but when I deploy it to the cloud it fails to perform the connection setup.

https://feedstream2p013234trial.netweaver.ondemand.com/feed_stream2/index.html

(this is just a simple demo in order to reproduce the problem)

This is what I believe is happening:

1. javascript client initializes and connects to the API REST service

(from console.log I can see the URL is correct https://feedstream2p013234trial.netweaver.ondemand.com/feed_stream2/api/feed/live?X-Atmosphere-track...

2. The server process the request correctly, and sets up a persistent connection with the client.

3. The persistent connection passes through some kind of proxy that introduce problems

4. The javascript event receiver onOpen is never called (therefore the program doesn't enable the input box)

The reason why I believe step 3. happens, is that I can reproduce the same problem locally if I am running Fiddler (a HTTP monitoring proxy).

Questions

1. Are there any infrastructure components in SAP NW Cloud that could explain this type of behaviour?
   (I know there is a load balancer)
2. Is the SSL termination done at the load balancer or on the tomcat application server?
3. Is it possible to disable SSL for a SAP NW Cloud application?
   (both in order to see if this related to the problems and to do network sniffing with wireshark )

Regards

Dagfinn

[thomas_walter · Accepted solution]

Hi Dagfinn,

I didn't fully understand whether the problem happens if you call from a NW Cloud application out to the internet or when you call from the internet to the NW Cloud application.

Answering your questions:

Are there any infrastructure components in SAP NW Cloud that could explain this type of behaviour?

As I wrote I didn't fully understand when the problem occurs. If you call into the application you go through a set of load balancers. If you call from your application to the internet there is a proxy in between.

 Is the SSL termination done at the load balancer or on the tomcat application server?

SSL is always terminated on the loadbalancer in the DMZ so the LB can look into the http packets. From the load balancer to the application server traffic is again reencrypted.

Is it possible to disable SSL for a SAP NW Cloud application?

No. Currently we allow only https in NW Cloud for security reasons.

Best regards,

Thomas

[Former Member · Accepted solution]

Hi Thomas,

The problem occurs when I call from the internet to the NW Cloud application.

I'll try to setup SSL locally as well, and see If I am able to reproduce the problem then.

My gut feeling says it is not SSL, but something else preventing the connections from staying open.

Most likely I'll wait for websockets support through the next version of tomcat, and see if the same problems occur there.

HTML Server Side Events (formerly EventSource) http://dev.w3.org/html5/eventsource/ is a pretty straightforward implementation. Basically a HTTP connection with mime type text/event-stream.

There is an interesting part from the W3C page that might be relevant

"Legacy proxy servers are known to, in certain cases, drop HTTP connections after a short timeout. To protect against such proxy servers, authors can include a comment line (one starting with a ':' character) every 15 seconds or so.
...
Authors are also cautioned that HTTP chunking can have unexpected negative effects on the reliability of this protocol. Where possible, chunking should be disabled for serving event streams unless the rate of messages is high enough for this not to matter."

Regards

Dagfinn