These are indeed two problems, but I have given up on the session side as I have adequately tested it. It doesn't work, but we also don't need it any more, so the whole thing is moot. We do want to use Websockets which will behave unexpectedly in a clustered environment if Adobe doesn't have the two servers communicating with eachother. However, just like you can maintain your own session/user state with your own code and data store, you can maintain sync of subscribers and communicated messages between servers with custom code and data store. I was curious if anyone had used Websockets in a clustered environment and had tackled this issue with some undocumented feature.
Charlie Arehart <[email protected]> wrote: But let's be clear: I didn't ask for confirmation of session replication. I was just talking about what seemed was a more potentially fundamental problem of whether sessions were being kept at all. So I was being more specific in my question : what do you see when you dump the session struct? A) Do you see any value in the session struct at all? (It's possible that the code is running in a directory where the controlling application.cfc or cfm does not even enable sessionmanagement.) B) More important, I was asking whether the dump of the session scope show the cfid/cftoken or jsessionid (if using j2ee sessions) changing on each refresh of that page doing the dump? If so, then clearly no session key is being passed in, and that would explain why it's not being persisted over multiple requests. You did say originally, "I wanted to test session data communication between the two for failover reasons, but it just didn't work." Perhaps I should ask: by "sessions data communication", do you really mean CF session management? If not, perhaps we are just talking past each other. :-) You then said, "I'm starting to think it doesn't actually work, and that I will have to write websockets that exchange data between the servers to keep everything in sync." Well, if you meant sessions, and if you find that the sessionid changes on each request, then it seems yes you would need to take extra steps to "exchange data" (session ids) to "keep everything in sync". But you then mention in the last note checking for session replication. That's an entirely different subject. If you confirmed above that sessions were indeed being kept on a given request, then the next question (without respect to web sockets, really) of whether the two instances were replicating sessions. If you take websockets out of the equation, do you see whether sessions are being replicated between the instances? If not, there can be any number of explanations for that. But those really are two different problems. Let's hear what you think about the above and we can proceed based on that. /charlie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kier Simmons Sent: Tuesday, August 27, 2013 11:25 PM To: [email protected] Subject: Re: [Possible SPAM] RE: [houcfug] Using Websockets in a Clustered Environment Yes. We dumped and monitored to see if there was any data replication from sessions across servers in the cluster. There was not. Websockets so not use session management. Essentially you subscribe to a Websocket, and it responds to subscribers when a change is made. However, I can't find any evidence of CF10 managing these subscriptions across servers. -- -- You received this message because you are subscribed to the "Houston ColdFusion Users' Group" discussion list. To unsubscribe, send email to [email protected] For more options, visit http://groups.google.com/group/houcfug?hl=en --- You received this message because you are subscribed to the Google Groups "Houston ColdFusion Users' Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the "Houston ColdFusion Users' Group" discussion list. To unsubscribe, send email to [email protected] For more options, visit http://groups.google.com/group/houcfug?hl=en --- You received this message because you are subscribed to the Google Groups "Houston ColdFusion Users' Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
