Hey Charlie, sorry for the late response. I work with Kier, and was doing a large part of the testing. In case it wasn't mentioned, we are not using Sticky Sessions, because doing so does not allow for persistent session variables in the case of a server failure. We are using J2EE sessions which is required for ColdFusion 10 session replication across clustered servers.
We did in fact take a look at the list of active sessions for both servers, and the application instance only existed on one of the two servers (whichever was being hit at the time). So there was no communication between the two servers that a session had been created and that it should be replicated. Server failover was working in that if one server went down, the other would take over, but the session ID and variables were not persistent (the session ID changed, and session variables cleared). What aggravates me is that the documentation from Adobe is so incredibly insufficient for what is to be expected from session replication, how to test it, how the servers must be configured, etc. At this point, I don't know whether it's not working because the servers aren't configured correctly, or if I'm just testing it improperly. I'd be willing to test the session replication again, but I would need to know that I'm either A) Testing it properly, or B) The servers are configured correctly. Trying to test one of the two without knowing that the other is correct is excruciating. I really appreciate any help or input. On Wednesday, August 28, 2013 9:05:34 PM UTC-5, charlie arehart wrote: > > Well, assuming you still want to confirm the real crux of your problem, > I'll > say again that it's not clear if you are saying that in testing > replication > (taking web sockets out of the equation), did your dump of the session > tokens show that they were the same value, over multiple requests and > within > the two servers on which you were making the requests? > > If they were not the same (within requests on one server), or between the > two servers, that would explain why it would seem that replication was > "failing". It could be that the sessions were replicated, but some other > issue left you unable to access it in your requests. Just something to > consider. > > As for proving whether the sessions were replicated (at all, whether you > were able to access them), since you mention having the server monitor, > you > could look at its list of active sessions, and see if a given set of > sessionids appears in the list of active sessions on both servers. If > there > wasn't a single one, then yes it would seem then that replication is not > working. If there are matches, then it would seem sessions are being > replicated, but then the next challenge is to be able to access them via > your browser requests. > > But again, I'll understand if you're past the point of wanting to dig in > further. > > /charlie > > -----Original Message----- > From: [email protected] <javascript:> [mailto: > [email protected] <javascript:>] On Behalf > Of Kier Simmons > Sent: Wednesday, August 28, 2013 9:46 PM > To: [email protected] <javascript:> > Subject: RE: [Possible SPAM] RE: [houcfug] Using Websockets in a Clustered > Environment > > 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. > > > > -- -- 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.
