I'll try...been a few months since I saw the issue. We have a JRun cluster of two instances ecah running CF6. A request for a graph in CF generates a swf and a graph id. The swf is requested via a call to /cfide/graph.cfm IIRC, with the graph id in the HTML on the resulting page. This graph id is not unique but is kind of unique to the CF instance. Thus if you have sticky sessions set to off, a user request to a cfm page that has a cfgraph in it may hit server A for the cfm page but hit server B for the swf request. But A generated the swf and ID and thus does not exist on B.
That about sums it up. Now, I actually setup a central CFIDE folder for both CF server A and B to see, but this didn't help. CF has some sort of internal numbering for each graph. DK On 11/27/05, Andrew Stevens <[EMAIL PROTECTED]> wrote: > Douglas, can you elaborate on this point? > > Cheers, > AS > > -----Original Message----- > From: Douglas Knudsen [mailto:[EMAIL PROTECTED] > Sent: Saturday, 26 November 2005 4:46 AM > To: CF-Talk > Subject: Re: session load balancing [WAS Re: Pros/Cons Session vs Client > scope] > > I'll point out that if you have a CF(JRun) cluster set to use > "non-sticky sessions" this will kill use of CF Graphing. AFAIK, there > is no work around. Just an FYI > > DK > > On 11/25/05, John Paul Ashenfelter <[EMAIL PROTECTED]> wrote: > > On 11/23/05, Dave Watts <[EMAIL PROTECTED]> wrote: > > > > > > How do you span sessions across ColdFusion servers if you > > > > > > aren't using Enterprise? > > > > > > > > > > You don't. > > > > > > > > Isn't it all a matter of how you cluster the machines though? > > > > I mean, if you want to use sessions in a clustered environment, > > > > you just need to make sure that your load balancer uses sticky > > > > sessions. Basically, the goal is not to ever toss users between > > > > servers, but just assign users to a server based on the load > > > > balancing parameters when they first land on your site. > > > > > > If you do that, you aren't spanning sessions across CF servers. This > > > approach is often referred to as "sticky sessions". If you use sticky > > > sessions, you don't get failover, only load-balancing. This may or may > not > > > be acceptable, depending on your business needs and general server > > > stability. > > > > Furthermore, you get a less powerful version of load-balancing -- > > incoming initial user sessions are balanced according to load (or > > whatever balancing scheme is being used) but once the user is *on* a > > server, they're on it for the sessions (thus the "sticky"). So if a > > server slows down b/c of a runaway process for example, *new* users > > get balanced to the less loaded servers, but the folks on the server > > with the slowdown are stuck. > > > > This is in contrast to active loadbalancing without sticky sessions > > where the user gets the least loaded server (or whatever is set in the > > balancing rubric) on *every* request. > > > > As an aside, implementing session-aware clustering can actually > > degrade performance, even when done "right". Using files to store > > session for example, is a common approach in both the LAMP stack and > > RubyOnRails for scaling horizontally across N servers -- but your > > chokepoint becomes the SAN or whatever storing the data. Even more > > advanced solutions like memcached (eg LiveJournal and Slashdot) or > > J2EE session clustering (eg CFMX) have problems b/c replicating data > > between multiple nodes takes time when the data is very active. > > > > It's always a balance of reliability vs performance. > > > > -- > > John Paul Ashenfelter > > CTO/Transitionpoint > > (blog) http://www.ashenfelter.com > > (email) [EMAIL PROTECTED] > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225327 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
