Hey guys, sorry for the delay in responding, myself.

So bottom line, you have confirmed that replication was not working as
expected.  That was what I was trying to drive at in my original notes, as
it seemed Kier was not leaning toward what seemed was a websockets session
persistence problem).

So now you can focus on why replication doesn't work. And I'll say that this
is not a new challenge for CF 10. Folks have had troubles with it for years,
whether (as you say) getting it to work at all, or configuring it properly,
or testing it properly.

I'll say also that even those who find it can work between instances on a
single machine will often find that they can't get it to work between 2
different servers, as you are trying to do here.

In CF10, specifically, there is some specific extra configuration you need
to do in the server.xml file (a new Tomcat-specific file). This is
documented at the bottom of the CF Admin Guide page at

http://help.adobe.com/en_US/ColdFusion/10.0/Admin/WSc3ff6d0ea77859461172e081
1cbf363c31-7ffa.html

And much the same info is offered at:

http://help.adobe.com/en_US/ColdFusion/10.0/Admin/WSc3ff6d0ea77859461172e081
1cbf3638e6-7fc2.html

Had you perhaps not noticed that? Or had you tried to make those changes,
and it's still not working?

If so, there is a blog entry from Aaron Longnion
(http://gianser.com/index.php/web-design-development/adobe-coldfusion/38971-
major-correction-coldfusion-10-cluster-setup-in-server-xml) who says that
that doc is wrong and that "After reading in this Tomcat 7 Cluster HOWTO
article that the Cluster XML node should be in the Engine or Host node, I
decided to move the Cluster node up from below the Host node to up into the
Host node."

Then again, comments from two others say it didn't work for them.

No question, getting session replication among multiple servers is a
delicate operation. More than that, consider also that once two or more
instances are replicating between each other, there's quite a bit of
overhead: 

a) a potentially significant memory impact is that EVERY session on each
instance needs to be replicated to the other, which means if you had 1000
sessions created by users running requests on instance a, and you had 1001
sessions created by requests on instance b, with replication you'd now have
2001 sessions on BOTH machines because those of each are replicated to the
other
b) a potentially more significant network bandwidth impact is that EVERY
change of a session (to any and all changed sessions) needs to be
communicated back and forth among the replicated instances 

As the CF docs there say (and many would recommend), you really ought to
consider using something else, like client vars stored in a database. (It's
not that they're saying replication doesn't work, or that one shouldn't use
it. Just that it's always worth considering carefully if it makes sense.)

And my point in addressing the original concern Chris raised was to help
discern whether his problem was indeed with websockets or perhaps
replication. Seems clear now that it's the latter.  If you do get it
working, let us know. (I have not tried to do it yet myself on CF10.)

/charlie

 

From: [email protected] [mailto:[email protected]] On Behalf
Of Chris Brown
Sent: Tuesday, September 03, 2013 12:30 PM
To: [email protected]
Subject: Re: [Possible SPAM] RE: [houcfug] Using Websockets in a Clustered
Environment

 

Hey Charlie, sorry for the late response. I work with Kier, and was/am 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 fail over 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.

-- 
-- 
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.

Reply via email to