Handle failover for MessagingServlet.

[subashk]

We are using SmartClient 7.0rc3 Power Edition.

Have a scenario where we have 2 servers doing loadbalance, and when the user connects to server1 we make it sticky and all requests goes to that server.

But when server1 goes down, the loadbalancer redirects the following requests to server2.

Is there anyway we can capture the status code on Messaging servlet, if it's not 200, to reload the page so the user is connected to server2.

Please let us know is there any better solution.

Thanks.

[Isomorphic]

What you should see is that the HTTP connection to server1 is severed, so the Messaging system reconnects, and your load balancer directs the new connection to server2 (without the Messaging system even knowing this has happened). If you're seeing something different, please explain exactly what you're seeing and what tools you are using to diagnose what's going on.

[subashk]

We are using HTTPAnalyzer/Fiddler to trace the req/resp.

The issue here is we initialize something on server 1 and that info is not in server2, so in order to reinitalize we need to reload the page.

So we want to capture that and send some response back to Messaging channel which can be intercept on client side and invoke page reload.

[Isomorphic]

The Messaging system works around any failures assuming they are intermittent. This is not a good place to look for a failover solution - use another, more common approach such as detecting server failure via lack of a regular "heartbeat" being delivered. Or, build your server in a way that doesn't rely on sticky sessions, which is a fragile approach.

[subashk]

When the server goes down, i see these requests with 0 bytes received and no status code, it doesnt even try the reconnect option.

These are our messaging configuration in server.xml

# RealtimeMessaging configuration
# how often do we send keepalives to the client (ms)
messaging.keepaliveInterval: 30000
# how long the client waits after the keepaliveInterval before re-establishing
# the connection (ms)
messaging.keepaliveReestablishDelay: 30000
# how long the client waits for the connect handshake to complete before
# retrying
messaging.connectTimeout: 20000
# connection time to live - the maximum amount of time a persistent connection
# is allowed to stay open before being re-established (ms)
messaging.connectionTTL: 120000
# total response size to pad out to in order to defeat intervening
# bufferring by proxies (bytes)
messaging.flushBufferSize:4096


65 10:38:12:577 ****** POST 0 (None) http://myserver:8088/web/isomorphic/...=1300981099717
66 10:38:32:624 ****** POST 0 (None) http://myserver:8088/web/isomorphic/...=1300981119764
67 10:38:52:702 ****** POST 0 (None) http://myserver:8088/web/isomorphic/...=1300981139827
68 10:39:12:749 ****** POST 0 (None) http://myserver:8088/web/isomorphic/...=1300981159889
69 10:39:32:811 ****** POST 0 (None) http://myserver:8088/web/isomorphic/...=1300981179952
70 10:39:52:874 ****** POST 0 (None) http://myserver:8088/web/isomorphic/...=1300981200015
71 10:40:12:936 ****** POST 0 (None) http://myserver:8088/web/isomorphic/...=1300981220078
72 10:40:33:014 ****** POST 0 (None) http://myserver:8088/web/isomorphic/...=1300981240140
73 10:40:53:077 ****** POST 0 (None) http://myserver:8088/web/isomorphic/...=1300981260203
74 10:41:13:124 ****** POST 0 (None) http://myserver:8088/web/isomorphic/...=1300981280266

[Isomorphic]

This suggests an issue with your load balancer. The client-side Messaging system has no control over which server receives requests. If they are being routed to a server that is down, that's a load balancer issue.