[undertow-dev] InMemorySessionManager.java performance

[Andrew Schmidt]

My company is currently switching from jboss 4 => wildfly 8.1,   jsf + hibernate + richfaces.  (We develop on Windows) 

After profiling our application, I've found some major performance penalties in the InMemorySessionManager.java in undertow.   Specifically in the bumpTimeout() that gets called on every getAttribute call.  Each of these calls takes 15 ms, which  when called 100 times during the course of a jsf request,  adds up.  (The 15 ms occurs when the execute.executeAfter in netty tries to wake up another thread)

Looking over the code:
io/undertow/server/session/InMemorySessionManager.java

-- snip
synchronized void bumpTimeout() {
            final int maxInactiveInterval = getMaxInactiveInterval();
            if (maxInactiveInterval > 0) {
                long newExpireTime = System.currentTimeMillis() + (maxInactiveInterval * 1000);
                if(timerCancelKey != null && (newExpireTime < expireTime)) {
                    // We have to re-schedule as the new maxInactiveInterval is lower than the old one
                    if (!timerCancelKey.remove()) {
                        return;
                    }
                    timerCancelKey = null;
                }
                expireTime = newExpireTime;
                if(timerCancelKey == null) {
                    //+1 second, to make sure that the time has actually expired
                    //we don't re-schedule every time, as it is expensive
                    //instead when it expires we check if the timeout has been bumped, and if so we re-schedule
                    timerCancelKey = executor.executeAfter(cancelTask, maxInactiveInterval + 1, TimeUnit.SECONDS);
-- snip

If the time changes by 1ms,  then the expiration task is cancelled and a new one is scheduled.    But this new scheduling takes 15ms.  Therefore every call to getAttribute (which in turn calls bumpTimeout) will constantly cancel and reschedule the expiration tasks.    This seems heavy handed.    Also the comment seems to imply that the developer who wrote this was aware that rescheduling is expensive, yet it happens on every call.

Disabling session expiration causes our application to run twice as fast.  (5.5 second page load goes down to 2.5)