[rle125]

I just notice that the long GET always happens when I miss a message.

I was able to test sending a message during a periodic reconnect, and it doesn't appear to be dropping any messages.

That tells me there is something extra that Messaging.unsubscribe() or Messaging.subscribe() is doing.

Adding a sleep on the server results in no loss of messages.

Therefore, it seems that the client is blocked for a moment.

[Isomorphic]

Messaging.unsubscribe() literally calls the exact same method as is used for periodic reconnect. So for that reason, obviously we don't really have a theory here.

Let's check some basics:

1. does this happen in any other browser?

2. can you replicate the problem on any other machine aside from your personal workstation?

3. can you replicate it with a version of Firefox that's still supported (by Mozilla we mean)

4. are you absolutely sure you are still subscribed to the channel where you're missing messages after you call unsubscribe? there's no way that you do are doing something like unsubscribing from everything, then re-subscribing to some channels?

[rle125]

1. We only support Firefox
2. Other developers have seen this issue. It actually occurs in numerous parts of our application.
3. I tested with Firefox 41 and it still happens.
4. Messaging.getSubscribedChannels() returns the channel that I am interested in.

Our application calls Messaging.unsubscribe() followed by Messaging.subscribe().

I tested with calls to Messaging.subscribe("", null) and Messaging.unsubscribe("") and it still does not work.

But commenting out either Messaging.unsubscribe() or Messaging.subscribe() does work.

[Isomorphic]

Wait.. you unsubscribe() from one channel but you still have a subscription to other channels, but then you call subscribe() again?

1. What is the new subscribe() call for? Another, unrelated channel?

2. Are you saying that removing the new subscribe() call corrects the problem with messages being dropped?

[rle125]

We have 2 ListGrids each holding their own channels.

ListGrid A (channelA) and ListGrid B (channelB) are both subscribed.

When the user clicks a button:

1. A client message is sent to the server.
2. ListGrid B (channelB) is unsubscribed and subscribed
3. A server message is sent back to the client, intended for ListGrid A (channelA).

ListGrid A remained subscribed to channelA.

But we can't guarantee that Step 2 finishes before Step 3. But adding a sleep before Step 3 seems to fix the problem.

It appears that any call to Messaging.subscribe() or Messaging.unsubscribe() regardless of the channel causes the drop.

[Isomorphic]

1. What is ListGridB unsubscribing and subscribing to? Is it the same channel?

2. Are you passing a new callback, not passing a callback, or passing null for the callback param?

3. If the callback change, is your code handling receiving a message on either the old *or* the new callback? For example, perhaps you have a bug where ListGridA is set up to receive data from the old callback, but not the new one

[rle125]

1. ListGrid B only ever subscribes/unsubscribes from channelB

2. We are passing the same callback. Never null, always the same instance.

3. ListGridA and ListGridB are completely separate in terms of channels and callbacks.

[Isomorphic]

OK, at this point, we're again without a theory, and your usage appears to be covered by existing tests that show no message loss, so we have nothing we can look into.

If you think message loss can be shown in the scenario described, the best thing would be to create a simple test case. There's no need for grids, or anything other than logging of messages received, since the Messaging subsystem knows nothing about any of that. You can use the code shown in this sample to build a simple servlet that injects server-side messages, without having to include your JMS provider or other infrastructure in the test.

Somewhere in building this test case, you will hopefully come across some detail of your usage that you forgot to share, which will explain this issue.

[rle125]

I get the following when trying the sample:

Developer Console - error encountered when checking if server timings are switched on - assuming the 'areServerTimesTracked' and 'trackServerTimings' built-in RPCs are disallowed, and hiding the UI for dynamic switching of server timing data
Messaging endpoint not responding - remote debugging unavailable. To fix, make sure you have correctly registered the Messaging servlet in your web.xml

[Isomorphic]

Right.. That error message is expected, and means what it says. That deployment is not configured to allow you to get timing data for server-side methods. As it should not be.

This doesn't seem to have anything to do with putting together a test case for a bug report.

[Isomorphic]

Oh if you mean the message about Messaging, as that message says, it's related to Remote Debugging, which you can read about in the docs package. Obviously, the sample is functional.