May 17, 2008
If you're on 64-bit Linux and you're using RewriteRule in Apache, you probably need this
Culmulative Hot Fix for ColdFusion 8.0.1. I hit this during testing and it was a blocker for Broadchoice to move from 32-bit Linux to 64-bit Linux (bug 71362). There are also four other bug fixes in this hot fix so check out the Tech Note.
Anyone else running ColdFusion 8.0.1 in production on 64-bit Linux or are we the first company to do so (on our twelve-server cluster)?
Comments
12 server cluster? :-) I guess they have a 2nd NIC and IP - have you monitored the traffic between servers? I'm curious what the overhead is for session replication on a large cluster, especially a busy site.
And if you have time for 1 more quick question please, what is each servers typical memory usage - I'm wondering if each server has to keep all of the servers' sessions in memory in case of failover?
Posted By Gary Fenton / Posted At
5/17/08 10:46 AM
We do not use session replication (and adobe.com does not use session replication, by the way).
I've always advised not using it (and Mike Brunt also mentioned this in his talk at cf.Objective() saying that there are many problems with it).
Posted By Sean Corfield / Posted At
5/17/08 11:24 AM
1st: I have installed this ColdFusion 8.0.1 Updater because it is recommended as a nice thing to do to each and every ColdFusion 8 installation. Have I done something wrong with this installation without a cause :-) ?
2nd: Session Replication: In the back of my head I remember there were CFC issues with that; but they should have vanished, shouldn't they ? So if session replication is still not recommended, what does this mean for ColdFusion apps which are meant to be highly scalable ? What is the concrete impact ? And the recommended workaround to avoid this probably bad impact ?
Posted By Kai Tischler / Posted At
5/18/08 7:47 AM
@Kai - 1 - some people are very nervous about updating their servers. Personally I like to be on the latest and greatest version, especially since 8.0.1 brings so many good things (like 64-bit support!). This latest hot fix for 8.0.1 just brings half a dozen extra bug fixes to 8.0.1.
@Kai - 2 - my issues with session replication have nothing to do with CFCs (although now that CFCs do replicate, you face the same problems with them that exist with duplicate() - it does a *deep* copy and that will break any code that stores a reference to a singleton into a transient object in session scope, e.g., using Transfer ORM and putting a user object in session scope). Session replication is not good in high-scale environments - there is latency between servers and a lot of network "chatter" if you use session scope heavily.
The recommended setup is no session replication and use sticky session on your hardware load balancer. If you have absolutely critical data in session (almost no applications actually do) then it makes sense to save it to a DB on changes and reconstruct it if the session data is missing (this is what adobe.com does with the shopping cart, for example).
Posted By Sean Corfield / Posted At
5/18/08 11:40 AM
Hey Sean,
Keep us up to date how this goes. We're planning a move to 64 bit and to clustering as well, so your thoughts/notes are very valuable.
Posted By Sami Hoda / Posted At
5/18/08 12:51 PM
@Sami, so far we've been very pleased with the 64-bit Linux / ColdFusion 8.0.1 setup. I'll have a better sense of how my JMS-based cache synchronization works shortly...
Posted By Sean Corfield / Posted At
5/18/08 1:03 PM
Hey Sean I am working with a client considering upgrading to 64 Bit CF 8.0.1 on Windows 2003. It was pretty exciting to be able to allocate 6GB to the JVM!
Posted By Pete Freitag / Posted At
5/19/08 12:26 PM
Adobe don't recommend using session replication? Huh? This prize feature lets users continue using the application while unaware that the server they were just using has just died or been taken down for maintenance. For some apps it's not okay to lose data that users have tried to submit or to throw them back to the login page when a server goes down. CF may take 20-30 secs to sort itself out after a server failure but it's better than kicking your users. It would be nice for CF9 to improve on that.
Are there alternative solutions perhaps?
Posted By Gary Fenton / Posted At
5/19/08 5:05 PM
@Gary, I didn't say anything about Adobe recommendations.
Session replication just does not work properly. You can fail over to a buddy server before the session data has fully replicated, CFCs are replicated as a deep copy and I've already explained - at length - why duplicate() on a CFC can be very dangerous.
Those are some of the reasons why adobe.com (and formerly macromedia.com) does not use session replication and why to this day I don't use it on high-traffic sites.
Posted By Sean Corfield / Posted At
5/19/08 7:01 PM
Gary, the problems with session replication aren't down to Adobe or CF. The problems are with session replication in general, as Sean has stated.
We implemented a high traffic ticketing system, think Ticketmaster, deployed on a cluster of Websphere servers and we used sticky sessions (enabled on the BigIP Load Balancer).
We saved user session information back to an Oracle DB so that it could be reconstructed.
No CF involved anywhere. The problem isn't CF or Adobe. Session Replication just sucks.
Posted By Andy Allan / Posted At
5/21/08 2:17 AM
Sean, Andy, thanks for your responses. Andy, did your solution involve writing code to manage session data and write it to a hand-made table in the db or do you just copy the session struct to a client struct? It must have a considerate impact on your db?
Hmm, now if only someone could blog about how to emulate session replication in a cluster without having to re-write an app that relies heavily on the session scope. :-)
Posted By Gary Fenton / Posted At
5/22/08 5:42 PM
I am a bit late commenting here. As Sean mentioned I do not typically advise reliance on Session Replication, mainly because I have worked with several clients who had problems with it. It is true to say that this is not a CF problem per-se but it is a Java-J2EE item. If I were designing an application from scratch I would probably defer to Client variables wherever possible although complex data types are a consideration point. My thought there would be to have a data model that mitigates the need for complex data types in the application code. One last point, I do advocate setting sticky sessions if using the session scope is unavoidable however that will unbalance load balancing to a certain extent.
Posted By Mike Brunt / Posted At
6/28/08 3:14 PM
Post Your Comments
Hosting provided by