Orange is my favorite color
January 5, 2011

ColdFusion - Web/Internet | Trackback | del.icio.us | digg

Working on a new server and I am debugging why startup is so slow. We are using multi-instance on JRun with two instances on a dual quad-core machine. The startup is taking forever (~300s) and I noticed this in the log file which I had never seen before:

info Recovering 719 session(s)

Turns out there was a corresponding line during shutdown:

info 719 session(s) persisted

Poking around the Internet, how to disable session persistence is an unanswered question. With some searching (mostly JRun-focused), you can find how to enable it but there is nothing on how to disable what is seemingly default behavior. This had stumped myself and at least two other experienced admins so I went hunting.

The first bit of useful information I picked up from the JRun docs is that session persistence across restarts is possible and the default behavior is to put it into files stored in the WEB-INF/sessions directory. Sure enough, I had about 700 files in there (in my case, in /opt/jrun4/servers/INSTANCE1/cfusion.ear/cfusion.war/WEB-INF). Deleted the contents of that directory so my next restart wouldn’t take so long. Progress!

Next was to investigate the WEB-INF/jrun-web.xml file which controls the session persistence config. The contents (minus comments) are quite short:

<jrun-web-app>
    <enable-jrun-web-services>false</enable-jrun-web-services>
    <session-config>
      <persistence-config>
        <active>false</active>
      </persistence-config>
    </session-config>
</jrun-web-app>

Well, that certainly looks right, but why are the sessions still being persisted? No session replication options were checked in the enterprise manager and there was no JRun or ColdFusion clustering enabled. What gives?

The answer is the added instances were missing the jrun-web.xml and the default behavior is to persist sessions! Copying in jrun-web.xml from the default “cfusion” instance in /opt/jrun4/servers/cfusion/cfusion-ear/cfusion-war/WEB-INF (and j2ee-web.xml, also missing, for good measure) resolved the problem and eliminated the session persistence and recovery with a restart.

Next quest to solve: Why JRun doesn’t pass java.ext.dirs from jvm.config to the underly JRE.

Update, literally 3 minutes after posting: So I’m moving on to my next quest, the above-stated java.ext.dirs conundrum and I type into Google: “jrun 4 java.ext.dirs” and up pops THIS post in spot #7! Google instant MEANS instant!

4 Comments

  1. Eric Cobb said:

    on January 5, 2011 at 12:18 pm

    Thank you! I had this problem about 2 months ago and could not figure out how to disable session persistence. We finally wound up just disabling J2EE session variables on all of our CF servers and that took care of it.

  2. brian said:

    on January 5, 2011 at 12:21 pm

    Eric – make this change and re-enable J2EE sessions. They are (generally speaking) better – more secure against session hijacking and automatically die when the browser is closed thanks to non-persistent cookies. You can also enable httpOnly cookies (look up Pete Freitag’s site for info).

  3. Andy Allan said:

    on January 6, 2011 at 7:23 am

    I’m assuming new instances were created using the Enterprise Manager in the cfusion instance. You don’t get this issue if you create your instances (EAR/WAR) via the actual installer.

    Due to the number of issues with the Enterprise Manager I gave up on it a long time ago.

  4. brian said:

    on January 7, 2011 at 8:39 am

    @Andy – quite possible, that was the trick here; I didn’t set them up, I just had to debug them. ;)

{ RSS feed for comments on this post}