Real-Time Messages not as reliable as expected

[siegersallee]

We're using GWT 2.6.1 and SmartClient Version: v9.1p_2014-06-04/PowerEdition Deployment (built 2014-06-04) and Eclipse Kepler SR2..

I got Real-Time messages working on a test basis within our (very large) SmartGWT application, with some help from this forum. (thanks!) You can refer to that post if you want to see code.

I set it up so the server pushes a message out using a Timer, every 3 seconds (after waiting a while to let everything get started). It also adds a serial number to every message.

I found that not every message is received. Specifically:

1. If the UI is busy building or tearing down a window for more than a second or 2, it will often drop a message, or even 2 messages.
2. Even when the UI is not busy, almost every time I let a test run for 1,000 messages, one is dropped, usually between 400-600.

When I say "a message is dropped", I mean that messages 28, 29, 30 and 32 are received, but there is no sign of message 31 on the client. It just vanishes without a trace. The server log shows that it is sent.

This happens with the LocalMessageDispatcher.

Surprisingly, it's the same when running hosted in Eclipse, or when deployed to a decent-sized Linux server and running in Firefox. When running using Classic Dev Mode, it loses about 15% of the messages, which is fine for Dev mode.

[Isomorphic]

We're not aware of a problem with Realtime messages being dropped as you describe.

Probably the best starting point here would be to see relevant the server logs.
We may also need a way to reproduce the problem, so if you can come up with a standalone sample we can run on our end to see these dropped messages that would allow us to debug things from our end.

Regards
Isomorphic Software

[Isomorphic]

To break this up a bit further:

1. for the case of dropping messages when the UI is busy - there is no plausible mechanism that could cause this to happen. We suspect that your application code may misbehave in some way that makes you think the messages did not arrive. The best thing to do would be to immediately log the receipt of each message when the Messaging callback fires, so there's no question of whether some downstream code of yours may be crashing

2. for the case of dropping 1 in a 1000 messages, one other user reported an (unreproducible) issue with messaging being dropped when the Messaging system does it's periodic reconnect (every 2 minutes by default). For this kind of dropping - when the UI is idle - do you see this happen at the same time as Messaging performs a reconnect? You can set the "Messaging" log category to DEBUG to see logs that indicate when reconnect occurs.

[Isomorphic]

One thing to try: enable debug logging for Messaging on the client and see if there's any useful information being reported at that threshold. Logging Preeference->More...->Add...->Category = "Messaging", select DEBUG threshold.