RT Messaging Keep-Alive handler

[bkelly]

We have had reports that RT Messages are intermittently undelivered. After reviewing prior posts on forum of a similar nature we have a question (perhaps a request). When the client loses the connection to the server it being making "keep alive" calls to reconnect. We can see the URL's getting called every second from a debugger or network monitor. From the debugger the message appear as "Sending data via frame isc_HiddenFrame_# ... /messaging/ts?=####### where the # are digits.  Is there an Event Handler or other mechanism we can use to notify the client application that the network connection is disrupted?

Essentially we would like to listen on the client side for such an event and post a message to the user so they are informed that the connectivity is disrupted and they may not receive message during this period. Further, it will help us eliminate a possible cause of a message not being delivered.

[Isomorphic]

We aren't aware of any bugs in the RTM module that are causing a failure to deliver messages. There are configuration/runtime scenarios where this could occur (for example a non-reliable server-side transport in combination with a firewall that aggressively cuts connections to the browser). There are configuration settings you could tweak to help with this (doc'd at the bottom of the page here: http://www.smartclient.com/docs/10.0...oup..messaging)

Can you provide a bit more detail around the cases that you're seeing? Are these messages that the client is sending that are not arriving at the server, the other way around, or both? What messaging mechanism are you using server-side?

Agreed that it would be useful to expose some of the internal connectivity state of the RTM module. Going to look into this...

[bkelly]

There are potentially multiple ways it can happen but the simplest to reproduce is as follows:

Connect to showcase demo of Real-Time Messaging from a remote client:
http://www.smartclient.com/smartgwte...g_stock_quotes

1. Watch the cell lights blinking.
2. Drop the network connection.
3. Lights stop blinking...

4. We observed when the connection is re-established the demo after a brief interruption, it "catches up" and appears to deliver the missed messages -- the rate of blinking accelerates.
5. However, if the disconnection is longer - say 5-minutes, the system does not "catch up" it sits their idle.

The key request is some API call that can detect if the connection to the web socket is lost so the user can be notified their screen is not alive. Whether this should return true after step 4 or step 5, isomorphic is best to judge.

[Isomorphic]

Just a heads-up that we are looking at this.

[Isomorphic]

There will be some new APIs in place to enable what you need in next Monday's (2015-11-9) build. You will get a callback that notifies you when the connection is established, and another when the connection is lost. Connection is considered concomitantly with the client-side attempting to re-establish a connection to the server. Which happens messaging.keepaliveReestablishDelay (default 1second) after messaging.keepaliveInterval (default 3 seconds) goes by without receiving a keepalive from the server.

You can tweak the above parameters and/or build on top of these new APIs to give the user the indicator you need.

In terms of the system "not catching up": we're not reproducing that here. The particular example you cited runs for 90 seconds and then the sender thread is terminated. In a synthetic experiment where this was bumped to 2 hours the network was brought up/down over that time frame, messages started arriving as expected when network connectivity resumed.

What might be happening with your scenario is that the broker in charge of the channel either gives up or runs out of queue space after a while. There should be options you can configure to trap this event and take some action (depending on whether you care to re-deliver all missed messages or not). With the new client APIs, you will be able to re-prime the system when connectivity is reestablished by sending a message up the channel and have a listener server-side that restarts the JMS queue (or whatever reliable mechanism you're using back there).

Sounds reasonable?

[Isomorphic]

Looks like it's going to be one more day. Wanted to make sure there was a working example in the SDK for this. Which version of SGWT are you looking to have this support in? While we usually do not backport new features, this particular one is safe...so long as we don't go too far back.

[bkelly]

Wanted to let the forum know that the changes made look good. They passed our internal testing and we plan to incorporate into future releases for our clients.