each request from the same client returns a different AtmosphereResource

[PavelR577]

tested on tomcat 7.0.28 64bit
windows xp/7 64bit
atmosphere 1.0.0.beta2a (0.9.4 as well)
spring 2.5.4 (spring 3 tested and got the same result)

1. client creates a websocket and subscribes to channel1 and channel2 and we suspend the resource.
2. client wants to unsubscribe from channel1 so he sends a POST using the same websocket - the AtmosphereResource that we get from the response is different from step1 so we can't unsubscribe him since we don't have his resource.

current work around - save the resource in a map on creation of the websocket and then we can access it later on.

To my knowledge the resource should be same for each POST from the same client (in other words it should persist per client).

[jfarcand]

The only issue I see what that approach is the AtmosphereResource has a reference to an AtmosphereRequest. The AtmosphereResource will needs to be updated on every new message with a new AtmosphereRequest instance (so you can read the message body). Looking....

[pierreh]

A better solution would be to send the AtmosphereResource UUID to the
client and that way you can use it to disconnect the connection.
The current default implementation of the WebsocketProtocol is in such a
way that it will give the same behaviour for the jquery and the gwt
client regardless of whether websockets or XHR are used to post to the
server.

On 7-7-2012 16:13, poi212003 wrote:

tested on tomcat 7.0.28 64bit
windows xp/7 64bit
atmosphere 1.0.0.beta2a (0.9.4 as well)
spring 2.5.4 (spring 3 tested and got the same result)

1. client creates a websocket and subscribes to channel1 and channel2 and we suspend the resource.
2. client wants to unsubscribe from channel1 so he sends a POST using the same websocket - the AtmosphereResource that we get from the response is different from step1 so we can't unsubscribe him since we don't have his resource.

current work around - save the resource in a map on creation of the websocket and then we can access it later on.

To my knowledge the resource should be same for each POST from the same client (in other words it should persist per client).

---

Reply to this email directly or view it on GitHub:
#488

[jfarcand]

@pierreh That would implies a new protocol where some information are sent back to the client after the handshake and as a WebSocket message. This is doable, but I prefer not to change anything for now.

@poi212003 Fixed, just retrieve the following attribute form any AtmosphereRequest

org.atmosphere.cpr.AtmosphereResource.webSocket.handshake

and the use the AtmosphereResourceFactory to retrieve the original AtmosphereResource.

[PavelR577]

working great!!
thanks!

[PavelR577]

a small bug - this attribute is not passed to the events (for example in the disconnect event I can't get it - it's always null)

[jfarcand]

Can you elaborate? On which Request are you setting the attribute? The first one?

[PavelR577]

I'm trying to get the uuid of the original request by getting this attribute:
org.atmosphere.cpr.AtmosphereResource.webSocket.handshake

When the user performs POST on the websocket, I'm able to get this attribute and retrieve the original resource,
but when the user closes the page for example or disocnnects and the diconnect event fires:

@OverRide
public void onDisconnect(AtmosphereResourceEvent event) {
//this doesnt work - returns a different handshake compared to the POST
event.getResource().getRequest().getAttribute("org.atmosphere.cpr.AtmosphereResource.webSocket.handshake");
super.onDisconnect(event); //To change body of overridden methods use File | Settings | File Templates.
}
I cant get the original uuid.

Hope that's clear

[PavelR577]

did you get to test it?

[jfarcand]

@poi212003 Yes, and also responded on the mailing list. I do have a test case that works as well.

[PavelR577]

ok - it looks like something else is messing it up - after I create a websocket then I refresh the page a new websocket it automatically created (I'm not doing anything at this point on the client side) and then the disconnect gets the uuid of the new websocket.

Can I control this? i dont want it to open a websocket automatically.

[PavelR577]

tested on firefox

[jfarcand]

@poi212003 Let's use the mailing list for questions :-) You just need to implement the onReconnect(request,response) function and close the request so no re-connect. Take a look at this

[PavelR577]

works like a charm! :)

Thanks.