Enterprise ColdFusion

I am entirely too obsessed with work and as a result I tend to only get to read the House of Fusion lists sporadically at best. I was reading it today and a topic crossed my eye that I had to check out "JREE Servers (was Session Management - sticky sessions)." Brad posed the question, how many people out there use something other than JRUN, or even multi-instance JRUN. I've often wondered this myself. In our Enterprise we've been running ColdFusion on JBoss for 2+ years now, we ran in CF7 unsupported. Over the course of the next few months I'm going to try harder to post some of our experiences with ColdFusion and Websphere. I'm also going to push one of my peers, Bob one of our Technical Leads, to start posting too. Bob has had a wealth of experience getting things up and running and has taught me a thing or 2 about connecting all the different pieces/parts together. Anyway, reply to the list or reply here but let everyone know, are you running ColdFusion on something other than JRUN?

Here's a quick rundown of our setup:
2 Different environments.

Environment 1: IHS, Jboss (4.2.1), mix of CF8 and CF7, AIX Servers with IBM 1.4
I do not have all the specifics on this environment b/c my involvement with it was limited. It runs half a dozen or so ColdFusion deploys concurrently. I am pretty sure it is load balanced across 2 servers.

Environment 2: IHS, Websphere (6.1), CF8, all sitting behind an F5 running on AIX.
This environment is a set of decked out P5 series IBM servers, 16 processors 100gig of ram. The processors are split up into 60 logical partitions with 40ish partitions dedicated to running 1-4 deploys of ColdFusion.
Our CMS on this cluster during peak AM hours supports about 10-15k sessions with peak around 60 simultaneous requests. Our LMS (my old system) once moved onto this cluster will serve about 5000 courses/hour during peak hours, push about 200 gigs of content/hour and process an average of 60 requests/second.

Some systems or libraries of interest we use/interact with: ACEGI, webMethods (well its in the works), IBM MQ series, Connect Direct, BMC's Enterprise Security Station (ESS), Lectora, Apollo, just about any database you can chuck at a system (for the search engines that includes Derby, Oracle, DB2, DB2 mainframe, MS SQL, MySQL, probably sadly Access).

Thermo

Thermo was announced and subsequently shown off at MAX this year but if you didn't attend you didn't get much more than a few blurbs about it on blogs. Adobe has now posted a great 45 minutes(ish) presentation on Thermo. Check it out here. Additional imformation is available on Adobe labs.

Open Source Projects

Open source is great for the community and for the developers behind the projects. It gives the developer(s) publicity and it also gives the developer(s) an opportunity to garner feedback from the community. I appreciate all the work that goes into open source and in an effort to improve a large portion of open source projects, notably frameworks that are out there, I want to bring up context roots. For all practical purposes context roots generally should not make a difference but I've now run into multiple projects that require modifications to work in an environment that runs on a context root other than /. When possible I make fixes and contact authors of the issue. Its not terribly difficult to fix generally but I have had experience that authors were not even aware of context roots. Since this has occurred multiple times I just want to try to make people aware of context roots and and explain them (I may over simplify this but I'd rather over simplify than over complicate).

To keep it simple I'll limit this explanation to deploying ColdFusion as a WAR file. When you deploy a JEE application to an application server each application lives in its own directory. The context root is (in many app servers) the name of the containing directory. So if I deploy my ColdFusion application as cfusion.war (this contains my CFML and the CFML engine) the context root is cfusion. Now if I want to visit the administrator I would visit, http://sam.pl/cfusion/CFIDE/administrator/index.cfm. Note the /cfusion/, this is the context root. Now on the flip side if I am in a ColdFusion page and want to use cfinclude to include that same CFM I would do <cfinclude template="/CFIDE/administrator/index.cfm">, note the lack of the context root. Generally context roots do not rear their ugly head, the most common place I see issues arise is when pages attempt to include static assets in HTML. You see things like an application is deployed to /wwwroot/myproject/ and static assets are referenced like /myproject/css/default.css. The fix is simple enough, #getPageContext().getRequest().getContextPath()#/myporject/css/default.css. There are other issues I've seen when projects try to calculate the paths, generally resulting in {path including WAR directory}\{context-root (put here by framework generally}\{path to project}. Most of these issues can be overcome by using expandPath() and other built-in functions. Hopefully this helps a couple of open source contributors that may not have been hip to context roots.