RealtimeMessaging - subscribe/unsubscribe

[rle125]

SmartGWT 5.0/Firefox 26

I've seen that when a client-side call to Messaging.subscribe()/unsubscribe() is occuring, server-side messages from ISCMessageDispatcher.send() appear to be dropped.

I've verified that adding a wait prior to the send() gets it working. It's as if the RealtimeMessaging client is blocked during Messaging.subscribe()/unsubscribe().

Is there a recommended solution to this behaviour?

[Isomorphic]

We're unclear on what you mean. A client that unsubscribes for a while should expect to miss any messages that were sent while the client was unsubscribed. These are real-time messages; they are not queued indefinitely for later delivery, as for example emails are.

[rle125]

I meant to say that the unsubscribe() or subscribe() calls are not for the channels that we are sending over. \

The javadoc mentions a "reconnect to the server", so what I observe is that ANY call to unsubscribe() or subscribe() appears to block and not receive ANY realtime messages over ANY channel

[Isomorphic]

Can you clarify that further - are you talking about one user's subscribe attempt influencing *other* users? And are you saying there's message loss?

There's not really any way we can see that that could happen... if you are using JMS, perhaps there is an issue with the JMS implementation you're relying on.

[rle125]

Same user using just the RealtimeMessaging API.

It appears as if the message is dropped when sent from server to client, while the client is performing either a Messaging.subscribe() or Messaging.unsubscribe().

Messaging.subscribe() and Messaging.unsubscribe() mention a "reconnect to the server". I'm guessing that during this time, messages from server to client are dropped?

Is there a way to determine that Messaging.subscribe() or Messaging.unsubscribe() has finished, or is in progress on the server side?

[Isomorphic]

So again, calling unsubscribe() would be expected to cause that client to stop receiving messages. There is a periodic, automatic reconnect that occurs once you have called subscribe(). In our testing, this periodic, automatic reconnect does not cause messages to be dropped (it is designed not to). The only way to make the server aware of an unsubscribe() would do to send a message to the server right before you do it. This is the only it could work with multiple servers.

[rle125]

When I say unsubscribe(), it was to unsubscribe from a different channel, not the channel that the message is being dropped on.

So in my tests, we are always subscribed to the dropped message.

[Isomorphic]

OK, that was a very key piece of information, and now your other posts make sense.

Unsubscribing from a channel is achieved by tearing down and rebuilding the connection to the server. This has to be done periodically anyway (every two minutes is the default) and, as we covered previously, this does not cause message loss in our tests. So the questions now would be:

1. what's the exact version you're using? If you aren't using the latest patched build, please retry with that build

2. do you also see message loss during the periodic reconnect? You can see it happening because you'll see a new request to the Messaging servlet

[rle125]

During the "tearing down and rebuilding" can messages be dropped? Or is there some queue that they are stored in?

I was on a 5.0p July nightly build. Will try the latest build.

[rle125]

I tried the October 28 2015 nightly and the problem still exists.

I enabled Server Logs and I do see the "messagingSend" log.

Is there logging on the client side that I can enable to get more information?

[Isomorphic]

So again:

Unsubscribing from a channel is achieved by tearing down and rebuilding the connection to the server ... as we covered previously, this does not cause message loss in our tests.

And we still need an answer to question #2 above:

2. do you also see message loss during the periodic reconnect? You can see it happening because you'll see a new request to the Messaging servlet

You said "the problem still exists" but you haven't answered whether you are also seeing message loss on periodic teardown and reconnect cycles.

Note that the way that teardown and reconnect works is to establish a new connection before getting rid of the old. If there is something weird about your messaging backbone where this strategy wouldn't guarantee that messages aren't missed, that would explain your issue.

As far as logs, while you can enable the "Messaging" client-side log category and look at it, really the most important thing is to answer question #2.

[rle125]

My test case consists of an operator invoked server side message sent to the client, so I'm not easily able to test if dropping occurs during a periodic reconnect.

I do see the reconnect every 2 minutes, followed by the keepalive every 3 seconds.

[Isomorphic]

We don't really follow why you can't test this case. Seems a matter of watching the clock and sending some messages at the right time.

And if you can't test this we're not sure how to proceed - we don't see messages dropped, and you haven't provided any way to reproduce the problem...

[rle125]

I will work on setting up this test case.

I noticed in normal Firefox Developer Console, when the server send is successful, the "GET https:/../sc/messaging" occurs fairly quickly (2secs). During the time of suspected messaging dropping, the "GET" call appears to hang. It looks like the unsuccessful GET is missing some information. The missing information is eventually filled in, and it looks just like the successful GET, but it consistently takes 120 seconds for that to happen.

Successful GET:

Request Method: GET
Status Code: HTTP/1.1 200 OK
Request Headers 13:16:27.000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
Referer: https://localhost:8443/myURL/?accept=true
Pragma: no-cache
Host: localhost:8443
Connection: keep-alive
Cache-Control: no-cache
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Accept: text/event-stream
Sent Cookie
JSESSIONIDSSO: pcBgq2n3X+J4Tsliio8bCcnV
JSESSIONID: 5GhqzlIX-ZivgKvvi9rkWHLw
GLog: { trackRPC:false, isc_pageURL:"https://localhost:8443/myURL/?accept=true", isc_pageGUID:"439AEC5F-48F6-4773-9E6E-BFFA5AD05C39", priorityDefaults:{ sgwtInternal:1, RPCManager:3, Messaging:5 }, defaultPriority:3, left:97, top:70, width:1006, height:812 }
Response Headers Δ34ms
Transfer-Encoding: chunked
Server: Apache-Coyote/1.1
Pragma: no-cache
Expires: Wed, 28 Oct 2015 20:16:27 GMT
Date: Wed, 28 Oct 2015 20:16:27 GMT
Content-Type: text/event-stream;charset=UTF-8
Connection: close
Cache-Control: no-cache

Unsuccessful GET:

Request Method:     GET
Status Code:    
Request Headers 13:16:34.000
User-Agent:    Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0
Referer:    https://localhost:8443/myURL/?accept=true
Pragma:    no-cache
Host:    localhost:8443
Connection:    keep-alive
Cache-Control:    no-cache
Accept-Language:    en-US,en;q=0.5
Accept-Encoding:    gzip, deflate
Accept:    text/event-stream
Sent Cookie
JSESSIONIDSSO:    pcBgq2n3X+J4Tsliio8bCcnV
JSESSIONID:    5GhqzlIX-ZivgKvvi9rkWHLw
GLog:    { trackRPC:false, isc_pageURL:"https://localhost:8443/myURL/?accept=true", isc_pageGUID:"439AEC5F-48F6-4773-9E6E-BFFA5AD05C39", priorityDefaults:{ sgwtInternal:1, RPCManager:3, Messaging:5 }, defaultPriority:3, left:97, top:70, width:1006, height:812 }

[Isomorphic]

Streaming works by having a GET request that is intentionally left incomplete so that more data can be sent periodically. So it's normal to see it left open for 120 seconds (the default amount of time we leave the connection open) - that would not constitute an "unsuccessful" GET.

We're note sure if you mean that this behavior correlates with message dropping or not. Please clarify.