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)?

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?

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

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 ?

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

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.

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

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!

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?

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

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.

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

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.

@Mike, I noticed that you would defer to client variables. Has anyone noticed client variable values corruption due to multiple web browser instances, or tab useage? I run a website @ work that sells insurance products, since they are a legally binding contract, we have been running into errors where people are opening 2 tabs and using our quoting engine to compare rates . . . as such the data gets corrupted. We don't have CFMX enterprise so storing values in seesions are our of the question (yes we are load balanced, and yes we have sticky sessions on, but the load balancer seems to be a little flaky sometimes). Any one have any ideas?

@Andrew, client variables are no solution to race conditions / thread-safety issues, as you've seen.

Like Mike, I never advise session replication, especially on JRun. I also never advise client variables - either you get a DB hit on every request or you're using cookies (or your foolish enough to use the registry :) If you have client variables set to cookies, why not just use cookies in the first place since you have more control over them manually.

My primary recommendation is session scope and sticky sessions (with a load balancer that actually works :)

...which provides no failover if a user has filled in a form and submits it just as the server he was using dies or is taken out of service.

I'd like to know more about Andy Allen's technique for cross-server session sharing via a db. (We have 1 to 3 db requests per page so 1 more wouldn't make much difference). I guess it's a company secret or Andy would have spilled the beans by now. :-)

@Gary, if a request is already committed to a server and that server dies, you will lose that request anyway. If the server dies before the request is committed, the load balancer can route it to a different server. That's completely independent of session management.

adobe.com uses sticky session and no session replication. For the online store, it saves the cart to the DB on each request so that if your session is lost due to failover, it can recover your cart but it will make you re-authenticate in order to purchase.

There are occasional applications that require 100% availability and need to handle session failover but since that is the edge case, you're much better handling that by using an encrypted cookie for "identity" and recovering the session data from the DB if it isn't present. For example, a User object can be easily restored if you have the user identity cookied.

Session replication is expensive on a high traffic site with a decent sized cluster. Session replication also has latency issues so you can actually have failover and get out-of-sync session data - and, as noted above, if a request is already committed to a server and the server dies, session replication doesn't help you.

@ Sean

Unfortunately slightly off topic, but the load balnacer is set up for sticky sessions and as far as I know it is working. Client Vars. are being stored in MSSQL DB, problem that is arising is when someone starts an insurance application in more than one window. The load balancer sees this as the same session (therefore sticky) but the client variables become corrupted between the two browser tabs. Say a date in one window overrides a date in the other.

I don't think that even using Session scope would prevent this, since session.effectiveDate would exist and "have" to be written to each time. I guess my question is has anyone had this isssue before, and if so, how did you fix it. (Personally I'm at a loss ;) )

@Andrew, my point was that you have race conditions that you need to make code changes in order to avoid. I was just saying that switching to client variables wouldn't avoid the problems you are seeing - because you have an underlying problem in your application - and you're right that session variables alone won't solve it either.

You need to identify each workflow uniquely across requests, rather than relying on a simple server-side solution.

@Gary ... basically what Sean said above.

Hi,

We are trying to setup the Cluster Load balancing in CF8 server with 4 instances on 2 different physical boxes. Below is our server configuration details:

Fedora 9 64bit, CF 8 64 bit Ent-trail edition.

Setup Details: 2 Linux boxes, 2 CF instances on each box. CF is setup as given in different posts, in Multiserver environment. We created 2 instances of CF in both boxes called, CF1, CF2 in BOX1 and CF3, CF4 in Box 2.

Issue: The issue we are having here is, when we add a remote server Box2 instance to Box1, it shows "Network Error". Where as when we check the same using JRun Admin console, it says "The server "cf3" is unavailable for administration on its specified host "10.10.0.14". Please make sure that the server exists, and that at least one server is running and registered with the JMC on the given machine."

We have done following things after going through some posts,

- jrun.subnet.restriction=* - jrun.trusted.hosts=* - We telnet'ed to the running instances port nubmers on other box2 from box1 and vice versa and we are successfully able to connect to each of them from either boxes. - We have disabled firewall on both the servers.

Can you please guide us on the above. Let us know if - we need to do anything else as this is a 64bit server? - Is there any issue with 64bit edition of CF8 on Linux? - Do we need to first join the CF to web server then configure the instances?

It will be great if anyone can help us out of this situation. Thank you in advance.

@Atul, have a look at this blog post of mine, over on the Broadchoice blog: http://tinyurl.com/5obl99

In particular, note the section on ensuring the JRunProxyService is *not* deactivated on the various instances. That caused me a bit of a problem at first.

Name:
Email Address:
Comments *** Please note that all comments require moderation so it may be some time before your comment posts to this blog! ***
Remember My Information: