We are using the flex.messaging.services.RemotingService to call into Java objects. We specifically do not want to have this session as we wish to load balance with no session affinity in the cluster processing these requests. This worked fine with the 3.0 series BlazeDS but is rather less happy in the 3.2 release. Is there a way to turn off this session stuff and use the flex.messaging.services.RemotingService? -- presently it appears our options are:
Like the original poster, we encounter this error when our load balancer is set to have no session affinity:
[FaultEvent fault=[RPC Fault faultString="Detected duplicate HTTP-based FlexSessions, generally due to the remote host disabling session cookies. Session cookies must be enabled to manage the client connection correctly." faultCode="Server.Processing.DuplicateSessionDetected" faultDetail="null"] messageId="6ADC180B-250D-06E8-967A-F7581523B439" type="fault" bubbles=false cancelable=true eventPhase=2]
Thanks, Rod S.
Hi. The RemotingService uses the BlazeDS messaging system which requires session affinity. All the services (RemotingService, MessageService, etc.) communicate with the server over a channel. The channel needs to be able to talk back to the same server for things like Pub/Sub messaging to work. I see the point that session affinity shouldn't be required for remoting requests that are stateless, but in BlazeDS a number of services can share the same underlying channel so not requiring session affinity could break other services.
This issue has come up before. I even found some blog postings that documented workarounds, though they do require customizing/modifying BlazeDS.
I thought there would be a bug for this logged already but I couldn't fine one in the bug system. Feel free to log a bug if you feel it is important to have this.
I can think of a number of ways this could be resolved. One would be to have a stateless channel that didn't require session affinity. Another would be to have a mode in which the remoting calls bypassed the BlazeDS messaging system, similar to the way in which web service and http service requests can get made directly to a target server and not go through the BlazeDS proxy.
Currently you can call a RemoteObject in ActionScript using NetConnection. These messages are processed on the server by the flex.messaging.endpoints.amf.LegacyFilter class. Using NetConnection instead of the mx.rpc.remoting.RemoteObject class on the client might allow you to bypass the session detection on the server.
Hope that helps.
Thanks, that does help.
I have filed this as http://bugs.adobe.com/jira/browse/BLZ-443 as I think this is a valid and useful configuration. I put it in as a Feature Request as the current behavior sounds by design so I'm not sure "bug" would be an accurate representation. In the short-term we will likely have to revert to 3.0. Longer term I suppose either the feature will be provided or we'll have to build our own customized version.
In terms of rolling our own solution, we currently use the AMFChannel. I would be interested in your thoughts on how much work adding either the stateless channel or a property to one of the existing objects to make it operate this way might be and any tips on where to look, likely problems we'd have, etc?
Just noticing I never answered these questions of Alan's.
>>If the polling-interval-millis was set to, lets say, 30 seconds and in those 30 seconds (while the client is not conncted) 100 JMS messages came into
>>Will the client receive the 100 messages when it re-connects back with the FlexSession?
Yes, the client will receive the 100 messages that were sent/pushed to the server while the client was in between poll requests.
>> Or does the client have to be waiting in long poll to get the messages?
No. There is a message queue on the server that is associated with the client. As long as the client is actively subscribed to the destination, it doesn't have to be physically connected to the server to get new messages. The messages will stay in the queue until the client polls the server again.
Thanks for filing the feature request. Yes, I agree that it should be considered an enhancement and not a bug.
As far as rolling your own solution goes, I think the simplest thing to do would probably be to do what Martin talks about on his blog, which is to disable the duplicate session detection. This code as he points out is in the flex.messaging.endpoints.BaseHTTPEndpoint class in the setupFlexClient() method.
If you are also doing messaging with your BlazeDS application, I would create a new endpoint, basically a copy of AMFEndpoint that used your new version of BaseHTTPEndpoint.java and just use that endpoint for remoting, not for messaging.
The duplicate session detection code adds a layer of security in the case of messaging. It would prevent someone who guessed your client's subscriber id from polling the server for messages intended for you from another session. This shouldn't matter in the remoting case because there wouldn't be any state associated with the client outside the session.
Just to be sure I understand the ramifications of this solution, we'd
presumably end up with an empty (other than any default stuff) session for
every user on every node they'd sent a request to? That is, if my user
generated 5 requests and the load balancer sends them to 5 nodes, each node
is going to setup a session? Presumably this is rather inexpensive for empty
sessions of course.
Thanks, Rod S.
Yeah. That's right. You'd get a new session for every request which obviously isn't ideal but the amount of stuff being stored in the session or associated with the session should be relatively small. In addition to the J2EE session, I think a new flex.messaging.FlexSession and flex.messaging.client.FlexClient will get created.
Also, make sure you set the scope on the destination to "request" so that the remote object class that is instantiated doesn't get held onto by the session. You should also be able to set the session timeout on the server to something pretty short as the session isn't really being used.
Hate to resurrect an old thread, but are there any plans to allow a stateless remoting only mode for stateless load balancing? We're still using a modified version of blazeds with the duplicate session config turned off, but this isn't ideal (tons of sessions pile up, for one).
Europe, Middle East and Africa