Seaside 3.2 is not actually new, but we just recently switched to VAST 8.6.3, which ships with Seaside 3.2. Before that we were on VAST 8.6 and Seaside 3.1.x (x=I don’t remember exactly).

Among the numerous changes in Seaside 3.2 is the new session timeout configuration. Up to Seaside 3.1 the way to configure session timeouts was this:

app :=
        (WAAdmin register: self asApplicationAt: 'Buchhaltung').
app cache expiryPolicy configuration at: #cacheTimeout put: 2400.

This has been changed in Seaside 3.2. The change is not downward compatible. If you execute the snippet above, you get a doesNotUnderstand: #expiryPolicy exception.

The new way to do it is this:

app :=
        (WAAdmin register: self asApplicationAt: 'Buchhaltung').
app configuration at: #maximumAbsoluteAge put: 14400.
app configuration at: #maximumRelativeAge put: 2400.
app cache: app createCache.

This is not a dramatic thing per se, but I’d like to draw my readers’ attention to two important things.

First: you need to send the cache: setter to the WAApplication instance, otherwise, the settings you made before won’t be effective. I’m sure there is a reason for this and it is just the way it has to be…

Then there is this little anecdote. At first we just set #maximumAbsoluteAge and left the relativeAge alone, which means the default value of 30 minutes is effective. We didn’t really pay attention, because there were so many small and big things to do during our migration, we had to fix a few things in Glorp and such, and all seemed fine.

…until more an more users complained they got kicked out of our site in the middle of working. The first few times we heard about it, we thought that maybe these people were just forgetting that there had been a coffee break or a phone call and they sure must have been idle for 40 minutes.

But the calls were coming in and also people we’ve been knowing for a while and who know the system quite well started telling us that, no, they hadn’t been idle.

We still had no clue, because things had been working well for years and a few attempts to find something obvious had failed over and over again.

One day, a team member looked through some logs and found something strange: a few users re-login after a bit more than 40 mintes, not 50, not an hour and a half, just about 40-43 minutes after their previous login.

So we had a clue. Things went fast from then on 😉

So what had happened?

By setting maximumAbsoluteAge to 40 Minutes, we had told Seaside to kill every session after a maximum of 40 seconds, no matter if people had been idle or not. So what we actually had configured that a session will be killed after 30 minutes of inactivity (default) and definitely be killed after 40 minutes, even if the user is in the middle of entering data….

To many Seaside users, this will sure be old hats. To us it wasn’t and this is just a little “lesson learned” that may or may not be helpful to other Seaside users.

Have you had similar stupid errors by misconfiguring Seaside? Share your anecdotes in the comments or – even better – let’s start a blog parade on “Stupid Things I did in Seaside” to share such dang moments and help each other sail around these….

 

 

Advertisements