Terracotta Discussion Forums

I’ve been experimenting with Terracotta in JBoss for Session Clustering for a couple of weeks now and I am shocked by how much faster it is than the JBoss Cache based version of session clustering. In some of our applications we can have very large numbers of active sessions. The problem I see is, periodically, every app server is going to have to kick off a thread which iterates through every session to find those that have timed out, and invalidate them. Won’t that process fault in every session that terracotta has into the app server, and since every app server runs this process, won’t every session end up on every app server?

Good question. With Terracotta sessions, as you might know, Terracotta provides our Session Manager implementation built atop the core DSO (Distributed Shared Objects) technology. We have an invalidation implementation that accounts for the behavior you describe. We maintain a separate light-weight data-structure for session-reaping, that keeps track of session_id and last access time, so only those sessions that have expired need be reaped (so needless faulting of sessions to check the last access date time-stamp). There are also some additional affinity-related optimizations (and monitoring - e.g. hops can be tracked since the server that last serviced the session is written into the session cookie) to precisely avoid the loss of locality of reference behavior that you describe...
Hope that helps.
Iyer.

Here are the Terracotta Sessions properties that Iyer has mentioned and you can tune these as per your requirements:

###########################################################################################
# Section : Session properties (applies to all DSO session enabled web apps in this VM)
# id.length : The length (in chars) for session identifiers - min 8
# serverid : The server identifier to place in the session ID
# cookie.domain : Domain value for session cookie
# cookie.secure : Enable / disable the secure flag in the session cookie
# cookie.maxage.seconds : The maximum lifetime of the session cookie
# cookie.name : Name of the session cookie
# cookie.enabled : Enable / disable the use of cookies for session tracking
# maxidle.seconds : Session idle timeout in seconds
# tracking.enabled : Enable / disable session tracking completely
# urlrewrite.enabled : Enable / disable the URL functionality
# attribute.listeners : Comma separated list of HttpSessionAttributeListener classes
# listeners : Comma separated list of HttpSessionListener classes
# invalidator.sleep : Sleep time between runs of the session invalidator
#
# request.bench.enabled : Enable / disable request benchmark logging
# invalidator.bench.enabled : Enable / disable benchmark logging for session invalidation
#
# request.tracking : Enable / disable the stuck request monitor
# request.tracking.dump : Enable / disable thread dumping when stuck requests discovered (unix only)
# request.tracking.interval : Frequency (ms) of stuck request inspection
# request.tracking.threshold : Threshold (ms) before requests are considered "stuck"
# debug.hops : Log session hopping (ie. processing of session by more than one VM)
# debug.hops.interval : Number of hops between debug printing
###########################################################################################
#session.id.length = 20
#session.serverid =
#session.cookie.domain =
#session.cookie.comment =
#session.cookie.secure = false
#session.cookie.maxage.seconds = -1
#session.cookie.name = JSESSIONID
#session.cookie.path =
#session.cookie.enabled = true
#session.maxidle.seconds = 1800
#session.tracking.enabled = true
#session.urlrewrite.enabled = true
#session.attribute.listeners =
#session.listeners =
session.invalidator.sleep = 300
session.request.bench.enabled = false
session.invalidator.bench.enabled = true
session.request.tracking = false
session.request.tracking.dump = false
session.request.tracking.interval = 2500
session.request.tracking.threshold = 15000
session.debug.hops = false
session.debug.hops.interval = 100

The interesting one for you is session.invalidator.sleep property. You can write the properties you wish to override in a tc.properties file and drop it in the $TC_INSTALL_DIR/lib directory and the Terracotta runtime will use the one you specified to override the default.

For a complete list of properties, here is the raw version of the most updated tc.properties file in the Trunk branch - http://svn.terracotta.org/fisheye/browse/~raw,r=3057/Terracotta/dso/trunk/code/base/common/src.resources/com/tc/properties/tc.properties

Regards,
Kunal Bhasin.

Hello,
I when I put this
Code:

	
 <session-config>
 		<session-timeout>-1</session-timeout>
 </session-config>

in my web.xml of my webapp then a new Session keeps being created in each request.
Tried to uncomment
Code:

session.cookie.maxage.seconds=-1

in tc.properties file
but the problem remains.
Tried uncomment and also put the
Code:

-Dcom.tc.session.cookie.maxage.seconds=-1

in JAVA_OPTS
but the problem still remains.

PS: I 'm using Tomcat 5.5.20 - Terracotta 2.4

Hmm - could not quite understand what problem you are trying to solve and what the Terracotta issue is.

The session-timeout of -1 in Tomcat's web.xml implies that a given session never expires. It has nothing to do with a session being created on each request.

You are passing the system property correctly (com.tc.session.cookie.maxage.seconds) - so if you are disabling it in web.xml and passing it to the client JVM via -Dcom.tc.session.cookie.maxage.seconds=-1, then in essence you are making the session-timeout infinite again.

So is your goal to make the sessions never expire? In either case this seems orthogonal to the problem around a new session being created on every requests - for which you might need to look elsewhere.

Sorry for not being clear enough....

Problem: I want--> Session never expires.
In detail:

The session-timeout of -1 in Tomcat's web.xml implies that a given session never expires.

That is exactly what I want. Session never expires. And that is the reason that I put
session-timeout of -1 in web.xml
and
Code:

-Dcom.tc.session.cookie.maxage.seconds=-1

in JAVA_OPTS and
Code:

session.cookie.maxage.seconds=-1

in tc.properties (put it in both places because of the problem indicated in jvmroute post http://forums.terracotta.org/forums/posts/list/202.page )

The

session being created on each request

is the wrong behaviour that I do NOT want. but unfortunately I am having. I get this behaviour when:
-I add session-timeout = -1 in web.xml with no terracotta settings (which is expected - the behaviour I mean)
-I add session-timeout = -1 in web.xml with the appropriate setting described above (which is not expected - again the behaviour).

Thanx!

Spido

PS: I had another problem with setting the tc.properties.
I had a SessionListener in my web app. With no terracotta setting it works. When I put the settings (JAVA_OPTS switch and tc.properties file) the Session Listener is never called.(?!?) Why???

You seem to be confusing the cookie expire time and the session expire time. They might seem similar but they are different things.

The cookie expiration time defines a time period which the browser will use to determine whether or not the cookie should be sent along with requests (ie. an expired cookie will not be sent, and is usually furthermore purged from disk/memory at such time).

The session idle timeout is a concept that the web server uses to define a time period in which a session is valid/accessible.

The usual setup for cookies used for sessions is to say "-1" which is a magic value that means "keep/send this cookie for as long as the browser is open", it is not infinite, rather tied to the lifetime of the browser. I think the only way to get something close to infinite cookie lifetime is to set the expires time to the max allowed value -- something in year 2038

So it seems you want to have no session idle timeout on the server side if I understand you correctly. I'll need to look into how the terracotta code is interaction with <session-timeout> values of -1 in web.xml under tomcat. It is possible that we are not correctly honoring that.

To use a tc.property to get an infinite session idle timeout, you'll want to set session.maxidle.seconds, and leave the session.cookie.maxage.seconds alone.

I missed the last point about session listeners....

Is the session listener defined in web.xml or in tc.properties? They should both work, but tc.properties will take precedence over web.xml -- futhermore, setting things in tc.properties will effect all terracotta web apps for that VM.

I recommend using web.xml to define your session listeners.

Is your web.xml within your war, or are you using a web.xml that has cross context scope. Tomcat lets you define a common web.xml that applies to all webapps for a given container. It's possible that we don't pick up listeners in that configuration.

One more note about HttpSessionListener in particular is that you can get the sessionDestroyed() callback on a node different from the one that received sessionCreated() -- this has to do with the distributed nature of session invalidation in our product.

Session tomeout:

You seem to be confusing the cookie expire time and the session expire time. They might seem similar but they are different things.

I was confused... Maxage seems much more familiar with session-timout than maxidle. I got lost along the way of guessing the tc.properties settings...

I wanted to find the equivalent of session-timeout, which is session.maxidle.seconds, correct me if I am wrong.
That's is why I did the post http://forums.terracotta.org/forums/posts/list/0/585.page#3214
So, from your reply on the post, it's ~24 days, which is too little for me.
So

I think the only way to get something close to infinite cookie lifetime is to set the expires time to the max allowed value -- something in year 2038

is not true.
I want sessions NEVER to timeout ideally. Or to be in order of years.

and leave the session.cookie.maxage.seconds alone.

that is not to set the maxage parameter but left the default value.

Session Listeners:
Session Listener are defined in the web.xml of my webapp - not the container's web.xml (that is the common web.xml). And it works OK with Terracotta too. But when I declare it in tc.properties file, it is not called. I thought that as far as there was a setting in tc.propeties file, I had to set it.
Thanx for the tip.

The fix has been pushed to the 2.5.0 code line and to trunk (revisions 6194 and 6195 respectively)

To get the update, you'll want to get a nightly build (with revisions >= the above numbers) for either 2.5.0 or trunk, which you can on our download page:
http://www.terracotta.org/confluence/display/orgsite/Download

These issues were resolved:
http://jira.terracotta.org/jira/browse/CDV-499
http://jira.terracotta.org/jira/browse/CDV-500
http://jira.terracotta.org/jira/browse/CDV-501

With those issues fixed, I think you should be able to get everything working without touching tc.properties at all.

You should be able to specify -1 in web.xml for <session-timeout> to get infinite idle timeout for sessions.

One thing that was definitely confusing here was that when a negative value was specified for session idle timeout, the terracotta code was instead using a a timeout value of 1 second! Good riddance to that bug.

THANK YOU VERY MUCH!!!

Sure thing, hope it fixes your issue(s)

So this is maybe obvious, but with an infinite session timeout, your app needs to be responsible for invalidating sessions itself if you want to reclaim the resources associated with them. I don't know enough about your application and the volume of session creation involved, but it really must be considered in my opinion. Using Terracotta sessions will mitigate/mask this problem somewhat since unused sessions will be flushed from memory as needed, but allowing session state to grow unbounded will eventually cause disk shortages and/or distributed garbage collection issues on the terracotta server.

There is a mechanism that invalidates sessions. That is why session timeout = -1
The nature of the application is such that a session might stay alive for whole years. To be honest with you this part of application code is not in my responsibility. And I must respect the requirements possed by the other developers.

allowing session state to grow unbounded will eventually cause disk shortages and/or distributed garbage collection issues on the terracotta server.

that's for sure... I must check this..

Thanx for the hints.

PS: Btw made a reply http://forums.terracotta.org/forums/posts/list/0/237.page#3234
asking for a tool that can list all the classes used in an application.
Do you happen to know one?

I'll comment on the question about a "tool for list classes used by an application" on the other thread.

Thanks for the info about how sessions are used in your application.

There is another bug that might be relevant to your use of session:

http://jira.terracotta.org/jira/browse/CDV-413

I could see bug biting you if there is code that tries to call invalidate() on a session from some sort of background thread (ie. not a thread servicing a servlet/jsp request)

You might want to see who calls invalidate() -- if you have any questions, just let me know here.