Take advantage of the largest STIC '12 conference discounts by registering this week

On Feb 8, 2012, at 4:12 AM, Johan Brichau wrote:

  Thanks, Johan! Yes, in my struggles to get daemontools to control my FastCGI Gem, I had
killed the maintenance gem and had forgotten to bring it back up. Now, I know what that
maintenance gem does in the system.

> You can also trigger session expiration manually. Look at the 'Seaside30' workspace when connected to the stone with a Gemtools session. There is the following expression that reaps the session cache:
>
> WABasicDevelopment reapSeasideCache.
>
> I must admit I do not remember why this difference exists with Pharo/Squeak versions.
>
> Hope that helps!
> Johan

Johan,

I thought that sessions timed out independently of the caching scheme ... the behavior could have changed since I last looked closely (a couple of years now), but I thought that sessions check internally against the expiry and the part that was split out for GemStone was the bit that tossed the expired sessions out of the cache ... this was broken out, because we don't need each of the web servers doing session cleanup and we'd have to protect them against conflicts ...

Dale

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, February 8, 2012 1:12:23 AM
| Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
|
| Hi Lawrence,
|
| On 08 Feb 2012, at 03:59, Lawrence Kellogg wrote:
|
| >  You know, now I am seeing sort of the opposite behavior, where a
| >  session stays up and active in my browser for hours.
| > Hmmm, did I delete something  by accident?
|
| Seaside in Gemstone works a bit different for session expiry than
| Seaside in Pharo/Squeak.
|
| In Gemstone, a separate gem process must explicitly expire Seaside
| sessions from the session cache. In the standard GLASS setup, this
| task is performed by the maintenance gem. So, you should check if
| your maintenance gem is running. The maintenance gem is started by
| the scripts delivered with GLASS. So running the following
| expression should start all seaside gems and the maintenance gems:
|
| WAGemStoneRunSeasideGems restartGems.
|
| You can also trigger session expiration manually. Look at the
| 'Seaside30' workspace when connected to the stone with a Gemtools
| session. There is the following expression that reaps the session
| cache:
|
| WABasicDevelopment reapSeasideCache.
|
| I must admit I do not remember why this difference exists with
| Pharo/Squeak versions.
|
| Hope that helps!
| Johan

Hi Dale,

I had the impression that the session could be reopened anytime if I disabled the session expiration task from running.
But I might be mistaken as well. I will check...

On 08 Feb 2012, at 18:02, Dale Henrichs wrote:

Dale,

By doing some experiments, I can confirm that when the session expiration task is not running, the seaside sessions remain accessible.

On 08 Feb 2012, at 20:15, Johan Brichau wrote:

Sounds like a bug then...

Dale

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, February 8, 2012 1:30:27 PM
| Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
|
| Dale,
|
| By doing some experiments, I can confirm that when the session
| expiration task is not running, the seaside sessions remain
| accessible.
|
| On 08 Feb 2012, at 20:15, Johan Brichau wrote:
|
| > Hi Dale,
| >
| > I had the impression that the session could be reopened anytime if
| > I disabled the session expiration task from running.
| > But I might be mistaken as well. I will check...
| >
| > On 08 Feb 2012, at 18:02, Dale Henrichs wrote:
| >
| >> Johan,
| >>
| >> I thought that sessions timed out independently of the caching
| >> scheme ... the behavior could have changed since I last looked
| >> closely (a couple of years now), but I thought that sessions
| >> check internally against the expiry and the part that was split
| >> out for GemStone was the bit that tossed the expired sessions out
| >> of the cache ... this was broken out, because we don't need each
| >> of the web servers doing session cleanup and we'd have to protect
| >> them against conflicts ...
| >>
| >> Dale
| >>
| >> ----- Original Message -----
| >> | From: "Johan Brichau" <[hidden email]>
| >> | To: "GemStone Seaside beta discussion"
| >> | <[hidden email]>
| >> | Sent: Wednesday, February 8, 2012 1:12:23 AM
| >> | Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
| >> |
| >> | Hi Lawrence,
| >> |
| >> | On 08 Feb 2012, at 03:59, Lawrence Kellogg wrote:
| >> |
| >> | >  You know, now I am seeing sort of the opposite behavior,
| >> | >  where a
| >> | >  session stays up and active in my browser for hours.
| >> | > Hmmm, did I delete something  by accident?
| >> |
| >> | Seaside in Gemstone works a bit different for session expiry
| >> | than
| >> | Seaside in Pharo/Squeak.
| >> |
| >> | In Gemstone, a separate gem process must explicitly expire
| >> | Seaside
| >> | sessions from the session cache. In the standard GLASS setup,
| >> | this
| >> | task is performed by the maintenance gem. So, you should check
| >> | if
| >> | your maintenance gem is running. The maintenance gem is started
| >> | by
| >> | the scripts delivered with GLASS. So running the following
| >> | expression should start all seaside gems and the maintenance
| >> | gems:
| >> |
| >> | WAGemStoneRunSeasideGems restartGems.
| >> |
| >> | You can also trigger session expiration manually. Look at the
| >> | 'Seaside30' workspace when connected to the stone with a
| >> | Gemtools
| >> | session. There is the following expression that reaps the
| >> | session
| >> | cache:
| >> |
| >> | WABasicDevelopment reapSeasideCache.
| >> |
| >> | I must admit I do not remember why this difference exists with
| >> | Pharo/Squeak versions.
| >> |
| >> | Hope that helps!
| >> | Johan
| >
|
|

Johan,

I'm curious about the experiments you've done ...

I've read some code and it isn't quite clear why the session is still accessible after expiration.

If you look at the method WACache>>at:ifAbsent: you'll see that if the object retrieved from objectsByKey  (presumably a session object) is expired, then the object is not returned ...

Soooo I am curious if your tests end up running through WACache>>at:ifAbsent: for session access or if the cache is being accessed from an alternate angle? Or perhaps the expiration test in WACache>>at:ifAbsent: is not correct for some reason...

Note the "Should we remove the object here?" question in  WACache>>at:ifAbsent:.

Dale
----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, February 8, 2012 1:30:27 PM
| Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
|
| Dale,
|
| By doing some experiments, I can confirm that when the session
| expiration task is not running, the seaside sessions remain
| accessible.
|
| On 08 Feb 2012, at 20:15, Johan Brichau wrote:
|
| > Hi Dale,
| >
| > I had the impression that the session could be reopened anytime if
| > I disabled the session expiration task from running.
| > But I might be mistaken as well. I will check...
| >
| > On 08 Feb 2012, at 18:02, Dale Henrichs wrote:
| >
| >> Johan,
| >>
| >> I thought that sessions timed out independently of the caching
| >> scheme ... the behavior could have changed since I last looked
| >> closely (a couple of years now), but I thought that sessions
| >> check internally against the expiry and the part that was split
| >> out for GemStone was the bit that tossed the expired sessions out
| >> of the cache ... this was broken out, because we don't need each
| >> of the web servers doing session cleanup and we'd have to protect
| >> them against conflicts ...
| >>
| >> Dale
| >>
| >> ----- Original Message -----
| >> | From: "Johan Brichau" <[hidden email]>
| >> | To: "GemStone Seaside beta discussion"
| >> | <[hidden email]>
| >> | Sent: Wednesday, February 8, 2012 1:12:23 AM
| >> | Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
| >> |
| >> | Hi Lawrence,
| >> |
| >> | On 08 Feb 2012, at 03:59, Lawrence Kellogg wrote:
| >> |
| >> | >  You know, now I am seeing sort of the opposite behavior,
| >> | >  where a
| >> | >  session stays up and active in my browser for hours.
| >> | > Hmmm, did I delete something  by accident?
| >> |
| >> | Seaside in Gemstone works a bit different for session expiry
| >> | than
| >> | Seaside in Pharo/Squeak.
| >> |
| >> | In Gemstone, a separate gem process must explicitly expire
| >> | Seaside
| >> | sessions from the session cache. In the standard GLASS setup,
| >> | this
| >> | task is performed by the maintenance gem. So, you should check
| >> | if
| >> | your maintenance gem is running. The maintenance gem is started
| >> | by
| >> | the scripts delivered with GLASS. So running the following
| >> | expression should start all seaside gems and the maintenance
| >> | gems:
| >> |
| >> | WAGemStoneRunSeasideGems restartGems.
| >> |
| >> | You can also trigger session expiration manually. Look at the
| >> | 'Seaside30' workspace when connected to the stone with a
| >> | Gemtools
| >> | session. There is the following expression that reaps the
| >> | session
| >> | cache:
| >> |
| >> | WABasicDevelopment reapSeasideCache.
| >> |
| >> | I must admit I do not remember why this difference exists with
| >> | Pharo/Squeak versions.
| >> |
| >> | Hope that helps!
| >> | Johan
| >
|
|

Dale,

Nothing fancy: I turned off the session expiration task that runs every 15 minutes.
My app is configured using the (standard) WARcLastAccessExpiryPolicy with a cache timeout of 600.

Next, I started a session, copied the url from the browser (including the _s & _k vars), closed the session, waited for an hour or so and then pasted that url back into the browser.

When session expiration is turned off, I get back to where I was in the application session.
When session expiration is turned on, I am redirected to the application start page (which is my login page).

I always understood that it was supposed to work that way in Gemstone, but I never really looked at the code for that.

Johan

On 09 Feb 2012, at 01:14, Dale Henrichs wrote:

On Feb 9, 2012, at 3:37 AM, Johan Brichau wrote:

  Yes, this was the behavior that I noticed. I thought it was cool, just like a desktop application.
Is there a problem with commit backlog? You're outside of a transaction, aren't you?

  As the main developer of my app, I would love a mode where I can stay logged in for hours
in order to do work. It is annoying to have to keep logging in every 10 or 20 minutes.

  Of course, I don't want to kill the maintenance gem so that everyone else stays logged in for hours and
I don't want to extend the time-out period either.

  Larry

Lawrence,

As long as a seaside session is being used, it should not expire.

For Seaside, that means that as long as requests come in for that session, it is kept alive.

A common trick is to include a script on the webpage that periodically makes an ajax call to the server [1].
That makes sure that, as long as the webpage is kept open in the browser, that the session is kept alive.

cheers,
Johan

[1] http://forum.world.st/Keep-alive-timer-for-Seaside-app-td3176635.html

On 09 Feb 2012, at 12:21, Lawrence Kellogg wrote:

>  As the main developer of my app, I would love a mode where I can stay logged in for hours
> in order to do work. It is annoying to have to keep logging in every 10 or 20 minutes.

On Feb 9, 2012, at 6:57 AM, Johan Brichau wrote:

> Lawrence,
>
> As long as a seaside session is being used, it should not expire.
>
> For Seaside, that means that as long as requests come in for that session, it is kept alive.
>
> A common trick is to include a script on the webpage that periodically makes an ajax call to the server [1].
> That makes sure that, as long as the webpage is kept open in the browser, that the session is kept alive.
>

  Yes, I know about keep alive, but I'm the only one who wants to remain alive, I want my inactive users to die off. ;-)
I don't want everyone on the site to be running the keep alive script, just me.

  I'll just extend the timeout period to a few hours on my localhost version. It's just that sometimes I am working
on one of the deployed images and I am always annoyed with the timeouts. It's easy to spend 20 minutes lost
in code, only to discover that your session has disappeared.

  Larry

Well this is a bug and the fact that it works the way it does is a mystery to me ... I won't be able to look into this right away, but I guess you should be forewarned that when I fix it the behavior will change:)

Dale

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, February 9, 2012 12:37:44 AM
| Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
|
| Dale,
|
| Nothing fancy: I turned off the session expiration task that runs
| every 15 minutes.
| My app is configured using the (standard) WARcLastAccessExpiryPolicy
| with a cache timeout of 600.
|
| Next, I started a session, copied the url from the browser (including
| the _s & _k vars), closed the session, waited for an hour or so and
| then pasted that url back into the browser.
|
| When session expiration is turned off, I get back to where I was in
| the application session.
| When session expiration is turned on, I am redirected to the
| application start page (which is my login page).
|
| I always understood that it was supposed to work that way in
| Gemstone, but I never really looked at the code for that.
|
| Johan
|
| On 09 Feb 2012, at 01:14, Dale Henrichs wrote:
|
| > Johan,
| >
| > I'm curious about the experiments you've done ...
| >
| > I've read some code and it isn't quite clear why the session is
| > still accessible after expiration.
| >
| > If you look at the method WACache>>at:ifAbsent: you'll see that if
| > the object retrieved from objectsByKey  (presumably a session
| > object) is expired, then the object is not returned ...
| >
| > Soooo I am curious if your tests end up running through
| > WACache>>at:ifAbsent: for session access or if the cache is being
| > accessed from an alternate angle? Or perhaps the expiration test
| > in WACache>>at:ifAbsent: is not correct for some reason...
| >
| > Note the "Should we remove the object here?" question in
| >  WACache>>at:ifAbsent:.
| >
| > Dale
| > ----- Original Message -----
| > | From: "Johan Brichau" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Wednesday, February 8, 2012 1:30:27 PM
| > | Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
| > |
| > | Dale,
| > |
| > | By doing some experiments, I can confirm that when the session
| > | expiration task is not running, the seaside sessions remain
| > | accessible.
| > |
| > | On 08 Feb 2012, at 20:15, Johan Brichau wrote:
| > |
| > | > Hi Dale,
| > | >
| > | > I had the impression that the session could be reopened anytime
| > | > if
| > | > I disabled the session expiration task from running.
| > | > But I might be mistaken as well. I will check...
| > | >
| > | > On 08 Feb 2012, at 18:02, Dale Henrichs wrote:
| > | >
| > | >> Johan,
| > | >>
| > | >> I thought that sessions timed out independently of the caching
| > | >> scheme ... the behavior could have changed since I last looked
| > | >> closely (a couple of years now), but I thought that sessions
| > | >> check internally against the expiry and the part that was
| > | >> split
| > | >> out for GemStone was the bit that tossed the expired sessions
| > | >> out
| > | >> of the cache ... this was broken out, because we don't need
| > | >> each
| > | >> of the web servers doing session cleanup and we'd have to
| > | >> protect
| > | >> them against conflicts ...
| > | >>
| > | >> Dale
| > | >>
| > | >> ----- Original Message -----
| > | >> | From: "Johan Brichau" <[hidden email]>
| > | >> | To: "GemStone Seaside beta discussion"
| > | >> | <[hidden email]>
| > | >> | Sent: Wednesday, February 8, 2012 1:12:23 AM
| > | >> | Subject: Re: [GS/SS Beta] Running SeasideGems, confusion
| > | >> |
| > | >> | Hi Lawrence,
| > | >> |
| > | >> | On 08 Feb 2012, at 03:59, Lawrence Kellogg wrote:
| > | >> |
| > | >> | >  You know, now I am seeing sort of the opposite behavior,
| > | >> | >  where a
| > | >> | >  session stays up and active in my browser for hours.
| > | >> | > Hmmm, did I delete something  by accident?
| > | >> |
| > | >> | Seaside in Gemstone works a bit different for session expiry
| > | >> | than
| > | >> | Seaside in Pharo/Squeak.
| > | >> |
| > | >> | In Gemstone, a separate gem process must explicitly expire
| > | >> | Seaside
| > | >> | sessions from the session cache. In the standard GLASS
| > | >> | setup,
| > | >> | this
| > | >> | task is performed by the maintenance gem. So, you should
| > | >> | check
| > | >> | if
| > | >> | your maintenance gem is running. The maintenance gem is
| > | >> | started
| > | >> | by
| > | >> | the scripts delivered with GLASS. So running the following
| > | >> | expression should start all seaside gems and the maintenance
| > | >> | gems:
| > | >> |
| > | >> | WAGemStoneRunSeasideGems restartGems.
| > | >> |
| > | >> | You can also trigger session expiration manually. Look at
| > | >> | the
| > | >> | 'Seaside30' workspace when connected to the stone with a
| > | >> | Gemtools
| > | >> | session. There is the following expression that reaps the
| > | >> | session
| > | >> | cache:
| > | >> |
| > | >> | WABasicDevelopment reapSeasideCache.
| > | >> |
| > | >> | I must admit I do not remember why this difference exists
| > | >> | with
| > | >> | Pharo/Squeak versions.
| > | >> |
| > | >> | Hope that helps!
| > | >> | Johan
| > | >
| > |
| > |
|
|