We did indeed dump the session vars, the application vars, the cookie tokens, used j2ee, set a var one way of you hit one server first and another way of you hot the other. We also used the server monitor tools that allow you to track sessions and applications. What happened in one server in the cluster did not replicate to the other. We even started playing with serializing components. Once you get that complicated, or is better to use your own central data store. As for Web sockets, I'm probably just going to use firebase and be done with it.
Charlie Arehart <[email protected]> wrote: Ok, but I would not conclude from your experience that "it doesn't work". You may feel you have "adequately tested it", but you've not offered enough proof of things in reply here. But I hear that you feel that it's a moot point and you've moved on. Fair enough. I just would want to counter the assertion that anything was necessarily broken, and that somehow it couldn't work for others. If that's not what you're saying, then no problem. I really am just trying to help, you and anyone else reading the thread. /charlie -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kier Simmons Sent: Wednesday, August 28, 2013 3:46 PM To: [email protected] Subject: RE: [Possible SPAM] RE: [houcfug] Using Websockets in a Clustered Environment 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. -- -- 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.
