HttpSessions not cleaned out, server grinds to a halt(?)

[nickarls]

Hi,

I'm sitting here with a memdump from a 7.1.1 (Win 64 Java 7) that, from what it appears, has ground to a halt. Well, it consumes so much memory (xmx2g) that the GC chews up the CPU

Attached are some screenshots from Eclipse MAT. It appears as I have poo-loads of sessions containing the one CDI @SessionScoped "Asetukset" object (from a producer method).

Looking at a sample session timestamp it shows it was created on June 18 with a lastAccessedTime of 0 and maxInactiveInterval of 900 but the dump is from June 21 and it's still shows as "isValid" true.

One single session is around 35k but a k here and a k there and soon we're talking G. Even if there would be some references to stuff in the session it wouldn't stop the session from timeout/cleanup, right?

Thankful for assistance,

   Nik

[jaikiran]

Doesn't your application invalidate sessions explicitly? I think (and I'm not really sure) the maxInactiveInterval will only be checked for if there's a subsequent access to the session after the timeout.

[nickarls]

Yes, the sessions are invalidated at normal logout. However, from the login screen, I sometimes see *two* sessions created. Don't know where the other one comes from but I thought it would just die away after a while ;-/

[jaikiran]

I guess it's that second session you'll have to track down and fix.

[nickarls]

Are there any conditions that could trigger the two-session-syndrome? A resource request GET from the same page?

[jaikiran]

Nicklas Karlsson wrote:

Are there any conditions that could trigger the two-session-syndrome?

Perhaps an easier way to track it would be to configure your implementation of HttpSessionListener http://docs.oracle.com/javaee/5/api/javax/servlet/http/HttpSessionListener.html and do a Thread.dumpStacktrace() in the sessionCreated() callback method.

[nickarls]

Hmm. I think it is something related to referencing a CDI SessionScoped bean from a session listener. The session context has some lazy loading mechanism for creating the backing storage (http session) on demand so the creation of a session creates a session (that gets abandon and hangs around)...

[jaikiran]

Perhaps a question for the Weld mailing list/forum then? If you do create that discussion, please link it here. I'm curious to see what it is.

[nickarls]

I though I got rid of this but apparently no. My next guess is that I have a DB-backed JSF ResourceHandler that uses an injected CDI dependent-scoped object that somehow get stuck.

But from a AS perspective, what is the reasoning that lastAcessedTime=0 session are (presumed to) be excluded from the cleanup? One would think that if they are iterated and chosen to be ignored, the assumption would be that they are always skipped and that would indicate knowledge that they are going to accumulate over time.

[jaikiran]

Moved this to JBossWeb forum. Someone there might have an answer.

[jfclere]

hm that session looks weird: isNew = true means that you just create it and it was never accessed by a request. It looks like you create it in your login/logout logic.

[nickarls]

This thingie in StandardSession probably explains why it's not cleaned out

(well the accessCount shows an AtomicInteger but it's probably 0 since the access time is 0)

 public boolean isValid() {

... 
        if (ACTIVITY_CHECK && accessCount.get() > 0) {
            return true;
        }
 ...
    }

I don't do anything unusual(tm), need to go over my JSF ResourceHandler. Perhaps something in my logout/session invalidation that creates a last, desparate session when going through the JSF lifecycle that sticks around

Any workarounds until then (short of slacking the second condition above and recompiling)?

Message was edited by: Nicklas Karlsson

[jfclere]

try -Dorg.apache.catalina.session.StandardSession.ACTIVITY_CHECK=false -Dorg.apache.catalina.STRICT_SERVLET_COMPLIANCE=false

[nickarls]

Hey, initial tests (5 session login/logout + Eclipse MAT) looks promising, I'll try to sneak it into production and then I can really tell. Thanks for the help, it'll keep me floating until I can trace the lifecycle of those strange sessions.