[jQuery][long-polling][XDR] IE9 does not reissue GET after receiving a message

[nite23]

This appears to be an issue with XDomainRequest, because connections on the same domain with enableXDR=false work correctly.

I have a broadcaster set up with scheduleFixedBroadcast to send a "ping" message to client every 30 seconds, to prevent timeouts.

when the client subscribes to the channel, browser issues a GET, which remains suspended until the ping arrives, then onMessage is called and another GET is issued and kept suspended.
The problem is, this always works only twice in a row. after the second message arrives, no more GETs are issued and the client thus cannot receive any more messages.

I noticed that each of the responses has a different X-Atmosphere-tracking-id header, could that be a problem?

[nite23]

update: if I issue a push() from the client right after connecting, there isn't even the second request.

here's a record of the communication:

• subscribe()

Request GET /at/c/e7f9eb21-af90-45dd-bdba-d1c7ff242b08?X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=1.1&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=text/plain HTTP/1.1

Response HTTP/1.1 200 OK
X-Powered-By Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2.2 Java/Oracle Corporation/1.7)
Server GlassFish Server Open Source Edition 3.1.2.2
Access-Control-Allow-Origin *
X-Atmosphere-tracking-id 37b279e0-407f-4387-9566-2ea51f709445
Expires -1
Cache-Control no-store, no-cache, must-revalidate
Pragma no-cache
Content-Length 2098

• push()

Request POST /at/c/e7f9eb21-af90-45dd-bdba-d1c7ff242b08?X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=1.1&X-Atmosphere-Transport=polling&X-Cache-Date=0&Content-Type=text/plain HTTP/1.1

Response HTTP/1.1 200 OK
X-Powered-By Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1.2.2 Java/Oracle Corporation/1.7)
Server GlassFish Server Open Source Edition 3.1.2.2
Access-Control-Allow-Origin *
X-Atmosphere-tracking-id 1f564ed8-f057-447d-a209-77c322570233
Content-Length 0

• (no more requests after that)

[jfarcand]

Target 1.0.5 for reproducing and fixing.

[jfarcand]

Can you try this and let me know if that help?

[nite23]

Tracking-id is now correct, and POST body is now attached as query string. But the issue still remains

Request GET /at/c/2765dea9-35a0-4ad9-a6db-aed54732162d?X-Atmosphere-tracking-id=35726720-94d5-de26-1d7b-ecc7c5ef29f3&X-Atmosphere-Framework=1.0.5&X-Atmosphere-Transport=long-polling&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=text/plain HTTP/1.1

Response HTTP/1.1 200 OK
X-Atmosphere-tracking-id 35726720-94d5-de26-1d7b-ecc7c5ef29f3

Request POST /at/c/2765dea9-35a0-4ad9-a6db-aed54732162d?X-Atmosphere-tracking-id=35726720-94d5-de26-1d7b-ecc7c5ef29f3&X-Atmosphere-Framework=1.0.5&X-Atmosphere-Transport=polling&X-Cache-Date=0&Content-Type=text/plain&X-Atmosphere-Post-Body=%7B%22payload%22%3A%7B%22type%22%3A%22ping%22%7D%7D HTTP/1.1

Response HTTP/1.1 200 OK
X-Atmosphere-tracking-id 35726720-94d5-de26-1d7b-ecc7c5ef29f3

Since the tracking-id is now correct I assumed HeaderBroadcasterCache could work. But enabling it resulted in client issuing GETs that got resumed immediately and reissued as fast as the connection could handle it.

[jfarcand]

@nite23 The behavior for resuming automatically is expected since retrieving a message from the cache during the suspend operation is like a broadcast, e.g the connection will be resumed.

[nite23]

yes, but what happens here is after the resuming client sends another GET, which gets resumed as well, then another every 30ms or so, until the client hits maxRequest limit.

[jfarcand]

Ah yes, unfortunately I cannot read the response's header with XDR, so I can set the X-Cache-Date value. I have the following in the code. Let me think about something...

[jfarcand]

Can you try this one and let me know if that helped? It will not be accurate as with normal request, but it could help.

[nite23]

Thanks, the BroadcasterCache now seems to work. I'll let it run for a while to see how reliable it is.
The connection still gets resumed after two requests, though.

On a related note, Chrome console shows a following mesage

• Refused to get unsafe header "X-Cache-Date"
• Refused to get unsafe header "X-Atmosphere-tracking-id"

So it appears, Chrome doesn't honor Access-Control-Expose-Headers header.

Could it benefit from the same workaround?

[jfarcand]

@nite23 use the request.dropAtmosphereHeaders so this exception won't happens. But X-Cache-Date won't be added properly. Let me work on a fix as well in that case

[jfarcand]

Try this and let me know. Make sure request.dropAtmosphereHeaders is set to false.

[nite23]

Well, this changes everything. I tried to add some debug messages to HeaderBroadcasterCache to test it, and I realized it wasn't even enabled. Sorry for misleading you. I assumed it was, because of messages like This message org.xxx.atmosphere.Message@1005f869 will be lost, adding it to the BroadcasterCache in the server log.
My atmosphere.xml was set up like this, and the broadcaster setting was ignored.

So I enabled it in web.xml. And, unfortunately, it doesn't work with CORS connections, in any browser. Server gets spammed with GETs that are resumed immediately.

In the file you posted, request.readResponsesHeaders returns true, but xdr.getResponseHeader("X-Cache-Date") returns null. So I forced readResponsesHeaders to false, but it didn't help.

But this issue is not that urgent, my application uses unique broadcaster id for every client, and i can write a simple BroadcasterCache implementation that takes advantage of this. The original problem with IE disconnecting is more important, and I haven't managed to find a workaround so far...

[jfarcand]

Really strange. I will see if I can reproduce the issue. Thanks as usual!

[jfarcand]

OK, this is now fixed, thanks to #680 . To enable it. Do on the client:

request.enableProtocol = true

On the server, use the BroadcasterCache called org.atmosphere.cache.EventCacheBroadcastListener (see #658)

[nite23]

Great, thanks!
Will this be included in the 1.1.0.beta3 release as well?

[jfarcand]

yes, it will.