Smalltalk › Gemtalk › GLASS

Set session duration

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

17 messages Options

keropotter

Set session duration

Hi!!

We're on a project, about to go live. But we're experiencing issues on session duration.

We're working with Seaside 3.0 on Gemstone 3.0.1 x64.

As I've seen on the Internet, it should be enough with this piece of code:

(WAAdmin defaultDispatcher handlers at: 'myAplicationName') cache expiryPolicy configuration at: #cacheTimeout put: 1200

(to get a 10 minutes long session).

This seems to be working ok on Pharo, but when we try on Gemstone and have multiple users working at the same time, the session times out at a random period of time, but never get to the 10 minutes we've configured de application for.

Has anybody experienced this issue? Is there a way to solve this?

Many thanks in advance!!
Alejandro

Paul DeBruicker

Re: Set session duration

On 12-04-12 01:45 PM, keropotter wrote:

> (WAAdmin defaultDispatcher handlers at: 'myAplicationName') cache
> expiryPolicy configuration at: #cacheTimeout put: 1200
>
> (to get a 10 minutes long session).
>
> This seems to be working ok on Pharo, but when we try on Gemstone and have
> multiple users working at the same time, the session times out at a random
> period of time, but never get to the 10 minutes we've configured de
> application for.
>
> Has anybody experienced this issue? Is there a way to solve this?

An alternate solution is to have the client ping the server every 9.5
minutes so the session stays alive as long as the client browser window
is open. And you can do that by adding this to a page:

| requestDuration |
requestDuration := 9.5 minutes.
html document
addLoadScript:
(html jQuery ajax
callback: [ ];
interval: requestDuration).

keropotter

Re: Set session duration

Thanks Paul, we'll try that. But I think it's still going to be a problem, since I set the session timeout to 20 minutes and got no further than 5... have you ever experienced this issue?

Thank you!

Ale

On Thu, Apr 12, 2012 at 6:33 PM, Paul DeBruicker [via Smalltalk] <[hidden email]> wrote:

On 12-04-12 01:45 PM, keropotter wrote:

> (WAAdmin defaultDispatcher handlers at: 'myAplicationName') cache
> expiryPolicy configuration at: #cacheTimeout put: 1200
>
> (to get a 10 minutes long session).
>
> This seems to be working ok on Pharo, but when we try on Gemstone and have
> multiple users working at the same time, the session times out at a random
> period of time, but never get to the 10 minutes we've configured de
> application for.
>
> Has anybody experienced this issue? Is there a way to solve this?

An alternate solution is to have the client ping the server every 9.5
minutes so the session stays alive as long as the client browser window
is open. And you can do that by adding this to a page:

| requestDuration |
requestDuration := 9.5 minutes.
html document
addLoadScript:
(html jQuery ajax
callback: [ ];
interval: requestDuration).

If you reply to this email, your message will be added to the discussion below:
http://forum.world.st/Set-session-duration-tp4553027p4553156.html

To unsubscribe from Set session duration, click here.
NAML

Dale Henrichs

Re: Set session duration

In reply to this post by keropotter

Hmmm,

This is a new one for me ... With 1200 you should be getting a timeout of 20 minutes.

I've heard of sessions not getting expired soon enough[1], but not too soon.

So let's start by finding out what class of expiryPolicy you are using. It should be an instance of WARcLastAccessExpiryPolicy.

I assume that you must be running the maintenance vm, otherwise the sessions will never be expired (Issue 332), but I think it would be useful to look at the log files for the you seaside servers and your maintenance vm ... if you could give me approximate times that you started each session and the approximate time that you saw the session begin expired, we might be able to correlate what's going on with information in the log ...

Given bug 332, as a workaround you can try changing the frequency of session expirations by editting WAGemStoneMaintenanceTask class>>maintenanceTaskExpiration and change the frequency from 1 second to 1200 seconds to match you expected expiration rate, but if the bug is in the expiration logic, your sessions will expire every 20 minutes anyway, so it's probably not a valid workaround...

Dale

[1] http://code.google.com/p/glassdb/issues/detail?id=332

----- Original Message -----
| From: "keropotter" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, April 12, 2012 1:45:37 PM
| Subject: [GS/SS Beta] Set session duration
|
| Hi!!
|
| We're on a project, about to go live. But we're experiencing issues
| on
| session duration.
|
| We're working with Seaside 3.0 on Gemstone 3.0.1 x64.
|
| As I've seen on the Internet, it should be enough with this piece of
| code:
|
| (WAAdmin defaultDispatcher handlers at: 'myAplicationName') cache
| expiryPolicy configuration at: #cacheTimeout put: 1200
|
| (to get a 10 minutes long session).
|
| This seems to be working ok on Pharo, but when we try on Gemstone and
| have
| multiple users working at the same time, the session times out at a
| random
| period of time, but never get to the 10 minutes we've configured de
| application for.
|
| Has anybody experienced this issue? Is there a way to solve this?
|
| Many thanks in advance!!
| Alejandro
|
| --
| View this message in context:
| http://forum.world.st/Set-session-duration-tp4553027p4553027.html
| Sent from the GLASS mailing list archive at Nabble.com.
|

Dale Henrichs

Re: Set session duration

Are the two sessions active during this time period or are they completely inactive?

Dale

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, April 12, 2012 3:46:52 PM
| Subject: Re: [GS/SS Beta] Set session duration
|
| Hmmm,
|
| This is a new one for me ... With 1200 you should be getting a
| timeout of 20 minutes.
|
| I've heard of sessions not getting expired soon enough[1], but not
| too soon.
|
| So let's start by finding out what class of expiryPolicy you are
| using. It should be an instance of WARcLastAccessExpiryPolicy.
|
| I assume that you must be running the maintenance vm, otherwise the
| sessions will never be expired (Issue 332), but I think it would be
| useful to look at the log files for the you seaside servers and your
| maintenance vm ... if you could give me approximate times that you
| started each session and the approximate time that you saw the
| session begin expired, we might be able to correlate what's going on
| with information in the log ...
|
| Given bug 332, as a workaround you can try changing the frequency of
| session expirations by editting WAGemStoneMaintenanceTask
| class>>maintenanceTaskExpiration and change the frequency from 1
| second to 1200 seconds to match you expected expiration rate, but if
| the bug is in the expiration logic, your sessions will expire every
| 20 minutes anyway, so it's probably not a valid workaround...
|
| Dale
|
| [1] http://code.google.com/p/glassdb/issues/detail?id=332
|
| ----- Original Message -----
| | From: "keropotter" <[hidden email]>
| | To: [hidden email]
| | Sent: Thursday, April 12, 2012 1:45:37 PM
| | Subject: [GS/SS Beta] Set session duration
| |
| | Hi!!
| |
| | We're on a project, about to go live. But we're experiencing issues
| | on
| | session duration.
| |
| | We're working with Seaside 3.0 on Gemstone 3.0.1 x64.
| |
| | As I've seen on the Internet, it should be enough with this piece
| | of
| | code:
| |
| | (WAAdmin defaultDispatcher handlers at: 'myAplicationName') cache
| | expiryPolicy configuration at: #cacheTimeout put: 1200
| |
| | (to get a 10 minutes long session).
| |
| | This seems to be working ok on Pharo, but when we try on Gemstone
| | and
| | have
| | multiple users working at the same time, the session times out at a
| | random
| | period of time, but never get to the 10 minutes we've configured de
| | application for.
| |
| | Has anybody experienced this issue? Is there a way to solve this?
| |
| | Many thanks in advance!!
| | Alejandro
| |
| | --
| | View this message in context:
| | http://forum.world.st/Set-session-duration-tp4553027p4553027.html
| | Sent from the GLASS mailing list archive at Nabble.com.
| |
|

Dale Henrichs

Re: Set session duration

I just tried an experiment using the default timeout in a 3.0.1 and I was able to keep two active sessions alive (in two tabs in the browser) while a third session in another tab expired ... I'll now bump the timeout up on the different apps I'm using and see what happens ...

I guess this test involved 3 different apps ... I'll try it with the same app ...

Dale

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, April 12, 2012 4:09:54 PM
| Subject: Re: [GS/SS Beta] Set session duration
|
| Are the two sessions active during this time period or are they
| completely inactive?
|
| Dale
|
| ----- Original Message -----
| | From: "Dale Henrichs" <[hidden email]>
| | To: "GemStone Seaside beta discussion" <[hidden email]>
| | Sent: Thursday, April 12, 2012 3:46:52 PM
| | Subject: Re: [GS/SS Beta] Set session duration
| |
| | Hmmm,
| |
| | This is a new one for me ... With 1200 you should be getting a
| | timeout of 20 minutes.
| |
| | I've heard of sessions not getting expired soon enough[1], but not
| | too soon.
| |
| | So let's start by finding out what class of expiryPolicy you are
| | using. It should be an instance of WARcLastAccessExpiryPolicy.
| |
| | I assume that you must be running the maintenance vm, otherwise the
| | sessions will never be expired (Issue 332), but I think it would be
| | useful to look at the log files for the you seaside servers and
| | your
| | maintenance vm ... if you could give me approximate times that you
| | started each session and the approximate time that you saw the
| | session begin expired, we might be able to correlate what's going
| | on
| | with information in the log ...
| |
| | Given bug 332, as a workaround you can try changing the frequency
| | of
| | session expirations by editting WAGemStoneMaintenanceTask
| | class>>maintenanceTaskExpiration and change the frequency from 1
| | second to 1200 seconds to match you expected expiration rate, but
| | if
| | the bug is in the expiration logic, your sessions will expire every
| | 20 minutes anyway, so it's probably not a valid workaround...
| |
| | Dale
| |
| | [1] http://code.google.com/p/glassdb/issues/detail?id=332
| |
| | ----- Original Message -----
| | | From: "keropotter" <[hidden email]>
| | | To: [hidden email]
| | | Sent: Thursday, April 12, 2012 1:45:37 PM
| | | Subject: [GS/SS Beta] Set session duration
| | |
| | | Hi!!
| | |
| | | We're on a project, about to go live. But we're experiencing
| | | issues
| | | on
| | | session duration.
| | |
| | | We're working with Seaside 3.0 on Gemstone 3.0.1 x64.
| | |
| | | As I've seen on the Internet, it should be enough with this piece
| | | of
| | | code:
| | |
| | | (WAAdmin defaultDispatcher handlers at: 'myAplicationName') cache
| | | expiryPolicy configuration at: #cacheTimeout put: 1200
| | |
| | | (to get a 10 minutes long session).
| | |
| | | This seems to be working ok on Pharo, but when we try on Gemstone
| | | and
| | | have
| | | multiple users working at the same time, the session times out at
| | | a
| | | random
| | | period of time, but never get to the 10 minutes we've configured
| | | de
| | | application for.
| | |
| | | Has anybody experienced this issue? Is there a way to solve this?
| | |
| | | Many thanks in advance!!
| | | Alejandro
| | |
| | | --
| | | View this message in context:
| | | http://forum.world.st/Set-session-duration-tp4553027p4553027.html
| | | Sent from the GLASS mailing list archive at Nabble.com.
| | |
| |
|

Dale Henrichs

Re: Set session duration

Okay ... I think I have a little more information for you ...

When you set the expiry policy the way that you do, you are only setting the expiry policy for the session and not for the continuations created by the session ... the continuations within the session are still expired at the default value of 5 minutes ...

so it probably isn't the session that is timing out on you, but some of the continuations in the session are being reaped after five minutes.

If you change the system default expiry (not exactly sure myself how to do that ... probably in the application configuration panel? ) you can effectively change the timeout for the continuations as well ...

I will poke around a little more to see how you can do this programmatically ...

In pharo, the expiration policy for continuations is probably a bit different which is why you are not seeing the same behavior on Pharo ...

Dale

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, April 12, 2012 4:25:36 PM
| Subject: Re: [GS/SS Beta] Set session duration
|
| I just tried an experiment using the default timeout in a 3.0.1 and I
| was able to keep two active sessions alive (in two tabs in the
| browser) while a third session in another tab expired ... I'll now
| bump the timeout up on the different apps I'm using and see what
| happens ...
|
| I guess this test involved 3 different apps ... I'll try it with the
| same app ...
|
| Dale
|
| ----- Original Message -----
| | From: "Dale Henrichs" <[hidden email]>
| | To: "GemStone Seaside beta discussion" <[hidden email]>
| | Sent: Thursday, April 12, 2012 4:09:54 PM
| | Subject: Re: [GS/SS Beta] Set session duration
| |
| | Are the two sessions active during this time period or are they
| | completely inactive?
| |
| | Dale
| |
| | ----- Original Message -----
| | | From: "Dale Henrichs" <[hidden email]>
| | | To: "GemStone Seaside beta discussion"
| | | <[hidden email]>
| | | Sent: Thursday, April 12, 2012 3:46:52 PM
| | | Subject: Re: [GS/SS Beta] Set session duration
| | |
| | | Hmmm,
| | |
| | | This is a new one for me ... With 1200 you should be getting a
| | | timeout of 20 minutes.
| | |
| | | I've heard of sessions not getting expired soon enough[1], but
| | | not
| | | too soon.
| | |
| | | So let's start by finding out what class of expiryPolicy you are
| | | using. It should be an instance of WARcLastAccessExpiryPolicy.
| | |
| | | I assume that you must be running the maintenance vm, otherwise
| | | the
| | | sessions will never be expired (Issue 332), but I think it would
| | | be
| | | useful to look at the log files for the you seaside servers and
| | | your
| | | maintenance vm ... if you could give me approximate times that
| | | you
| | | started each session and the approximate time that you saw the
| | | session begin expired, we might be able to correlate what's going
| | | on
| | | with information in the log ...
| | |
| | | Given bug 332, as a workaround you can try changing the frequency
| | | of
| | | session expirations by editting WAGemStoneMaintenanceTask
| | | class>>maintenanceTaskExpiration and change the frequency from 1
| | | second to 1200 seconds to match you expected expiration rate, but
| | | if
| | | the bug is in the expiration logic, your sessions will expire
| | | every
| | | 20 minutes anyway, so it's probably not a valid workaround...
| | |
| | | Dale
| | |
| | | [1] http://code.google.com/p/glassdb/issues/detail?id=332
| | |
| | | ----- Original Message -----
| | | | From: "keropotter" <[hidden email]>
| | | | To: [hidden email]
| | | | Sent: Thursday, April 12, 2012 1:45:37 PM
| | | | Subject: [GS/SS Beta] Set session duration
| | | |
| | | | Hi!!
| | | |
| | | | We're on a project, about to go live. But we're experiencing
| | | | issues
| | | | on
| | | | session duration.
| | | |
| | | | We're working with Seaside 3.0 on Gemstone 3.0.1 x64.
| | | |
| | | | As I've seen on the Internet, it should be enough with this
| | | | piece
| | | | of
| | | | code:
| | | |
| | | | (WAAdmin defaultDispatcher handlers at: 'myAplicationName')
| | | | cache
| | | | expiryPolicy configuration at: #cacheTimeout put: 1200
| | | |
| | | | (to get a 10 minutes long session).
| | | |
| | | | This seems to be working ok on Pharo, but when we try on
| | | | Gemstone
| | | | and
| | | | have
| | | | multiple users working at the same time, the session times out
| | | | at
| | | | a
| | | | random
| | | | period of time, but never get to the 10 minutes we've
| | | | configured
| | | | de
| | | | application for.
| | | |
| | | | Has anybody experienced this issue? Is there a way to solve
| | | | this?
| | | |
| | | | Many thanks in advance!!
| | | | Alejandro
| | | |
| | | | --
| | | | View this message in context:
| | | | http://forum.world.st/Set-session-duration-tp4553027p4553027.html
| | | | Sent from the GLASS mailing list archive at Nabble.com.
| | | |
| | |
| |
|

Dale Henrichs

Re: Set session duration

On pharo, you are keeping the last 20 continuations regardless of age and in gemstone you are reaping any continuations that are over 5 minutes old regardless of how many there are ...

Dale

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, April 12, 2012 5:08:35 PM
| Subject: Re: [GS/SS Beta] Set session duration
|
| Okay ... I think I have a little more information for you ...
|
| When you set the expiry policy the way that you do, you are only
| setting the expiry policy for the session and not for the
| continuations created by the session ... the continuations within
| the session are still expired at the default value of 5 minutes ...
|
| so it probably isn't the session that is timing out on you, but some
| of the continuations in the session are being reaped after five
| minutes.
|
| If you change the system default expiry (not exactly sure myself how
| to do that ... probably in the application configuration panel? )
| you can effectively change the timeout for the continuations as well
| ...
|
| I will poke around a little more to see how you can do this
| programmatically ...
|
| In pharo, the expiration policy for continuations is probably a bit
| different which is why you are not seeing the same behavior on Pharo
| ...
|
| Dale
|
| ----- Original Message -----
| | From: "Dale Henrichs" <[hidden email]>
| | To: "GemStone Seaside beta discussion" <[hidden email]>
| | Sent: Thursday, April 12, 2012 4:25:36 PM
| | Subject: Re: [GS/SS Beta] Set session duration
| |
| | I just tried an experiment using the default timeout in a 3.0.1 and
| | I
| | was able to keep two active sessions alive (in two tabs in the
| | browser) while a third session in another tab expired ... I'll now
| | bump the timeout up on the different apps I'm using and see what
| | happens ...
| |
| | I guess this test involved 3 different apps ... I'll try it with
| | the
| | same app ...
| |
| | Dale
| |
| | ----- Original Message -----
| | | From: "Dale Henrichs" <[hidden email]>
| | | To: "GemStone Seaside beta discussion"
| | | <[hidden email]>
| | | Sent: Thursday, April 12, 2012 4:09:54 PM
| | | Subject: Re: [GS/SS Beta] Set session duration
| | |
| | | Are the two sessions active during this time period or are they
| | | completely inactive?
| | |
| | | Dale
| | |
| | | ----- Original Message -----
| | | | From: "Dale Henrichs" <[hidden email]>
| | | | To: "GemStone Seaside beta discussion"
| | | | <[hidden email]>
| | | | Sent: Thursday, April 12, 2012 3:46:52 PM
| | | | Subject: Re: [GS/SS Beta] Set session duration
| | | |
| | | | Hmmm,
| | | |
| | | | This is a new one for me ... With 1200 you should be getting a
| | | | timeout of 20 minutes.
| | | |
| | | | I've heard of sessions not getting expired soon enough[1], but
| | | | not
| | | | too soon.
| | | |
| | | | So let's start by finding out what class of expiryPolicy you
| | | | are
| | | | using. It should be an instance of WARcLastAccessExpiryPolicy.
| | | |
| | | | I assume that you must be running the maintenance vm, otherwise
| | | | the
| | | | sessions will never be expired (Issue 332), but I think it
| | | | would
| | | | be
| | | | useful to look at the log files for the you seaside servers and
| | | | your
| | | | maintenance vm ... if you could give me approximate times that
| | | | you
| | | | started each session and the approximate time that you saw the
| | | | session begin expired, we might be able to correlate what's
| | | | going
| | | | on
| | | | with information in the log ...
| | | |
| | | | Given bug 332, as a workaround you can try changing the
| | | | frequency
| | | | of
| | | | session expirations by editting WAGemStoneMaintenanceTask
| | | | class>>maintenanceTaskExpiration and change the frequency from
| | | | 1
| | | | second to 1200 seconds to match you expected expiration rate,
| | | | but
| | | | if
| | | | the bug is in the expiration logic, your sessions will expire
| | | | every
| | | | 20 minutes anyway, so it's probably not a valid workaround...
| | | |
| | | | Dale
| | | |
| | | | [1] http://code.google.com/p/glassdb/issues/detail?id=332
| | | |
| | | | ----- Original Message -----
| | | | | From: "keropotter" <[hidden email]>
| | | | | To: [hidden email]
| | | | | Sent: Thursday, April 12, 2012 1:45:37 PM
| | | | | Subject: [GS/SS Beta] Set session duration
| | | | |
| | | | | Hi!!
| | | | |
| | | | | We're on a project, about to go live. But we're experiencing
| | | | | issues
| | | | | on
| | | | | session duration.
| | | | |
| | | | | We're working with Seaside 3.0 on Gemstone 3.0.1 x64.
| | | | |
| | | | | As I've seen on the Internet, it should be enough with this
| | | | | piece
| | | | | of
| | | | | code:
| | | | |
| | | | | (WAAdmin defaultDispatcher handlers at: 'myAplicationName')
| | | | | cache
| | | | | expiryPolicy configuration at: #cacheTimeout put: 1200
| | | | |
| | | | | (to get a 10 minutes long session).
| | | | |
| | | | | This seems to be working ok on Pharo, but when we try on
| | | | | Gemstone
| | | | | and
| | | | | have
| | | | | multiple users working at the same time, the session times
| | | | | out
| | | | | at
| | | | | a
| | | | | random
| | | | | period of time, but never get to the 10 minutes we've
| | | | | configured
| | | | | de
| | | | | application for.
| | | | |
| | | | | Has anybody experienced this issue? Is there a way to solve
| | | | | this?
| | | | |
| | | | | Many thanks in advance!!
| | | | | Alejandro
| | | | |
| | | | | --
| | | | | View this message in context:
| | | | | http://forum.world.st/Set-session-duration-tp4553027p4553027.html
| | | | | Sent from the GLASS mailing list archive at Nabble.com.
| | | | |
| | | |
| | |
| |
|

Dale Henrichs

Re: Set session duration

In reply to this post by Dale Henrichs

It doesn't look like there is any way to actually control the timeout used by the continuation cache without directly editing the code. The WASession>>createCache method looks like the following:

createCache
"To configure the continuation cache you must currently subclass WASession and
override this method."
^ WACache new
setExpiryPolicy: (WARcLastAccessExpiryPolicy new);
yourself.

it looks like if you change it to this:

createCache
"To configure the continuation cache you must currently subclass WASession and
override this method."

| policy |
policy := WARcLastAccessExpiryPolicy new.
policy configuration at: #cacheTimeout put: 1200.
^ WACache new
setExpiryPolicy: policy;
yourself.

you'll get both the session and continuation timeouts in synch ... this should probably get you going I would think.

Dale
----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, April 12, 2012 5:08:35 PM
| Subject: Re: [GS/SS Beta] Set session duration
|
| Okay ... I think I have a little more information for you ...
|
| When you set the expiry policy the way that you do, you are only
| setting the expiry policy for the session and not for the
| continuations created by the session ... the continuations within
| the session are still expired at the default value of 5 minutes ...
|
| so it probably isn't the session that is timing out on you, but some
| of the continuations in the session are being reaped after five
| minutes.
|
| If you change the system default expiry (not exactly sure myself how
| to do that ... probably in the application configuration panel? )
| you can effectively change the timeout for the continuations as well
| ...
|
| I will poke around a little more to see how you can do this
| programmatically ...
|
| In pharo, the expiration policy for continuations is probably a bit
| different which is why you are not seeing the same behavior on Pharo
| ...
|
| Dale
|
| ----- Original Message -----
| | From: "Dale Henrichs" <[hidden email]>
| | To: "GemStone Seaside beta discussion" <[hidden email]>
| | Sent: Thursday, April 12, 2012 4:25:36 PM
| | Subject: Re: [GS/SS Beta] Set session duration
| |
| | I just tried an experiment using the default timeout in a 3.0.1 and
| | I
| | was able to keep two active sessions alive (in two tabs in the
| | browser) while a third session in another tab expired ... I'll now
| | bump the timeout up on the different apps I'm using and see what
| | happens ...
| |
| | I guess this test involved 3 different apps ... I'll try it with
| | the
| | same app ...
| |
| | Dale
| |
| | ----- Original Message -----
| | | From: "Dale Henrichs" <[hidden email]>
| | | To: "GemStone Seaside beta discussion"
| | | <[hidden email]>
| | | Sent: Thursday, April 12, 2012 4:09:54 PM
| | | Subject: Re: [GS/SS Beta] Set session duration
| | |
| | | Are the two sessions active during this time period or are they
| | | completely inactive?
| | |
| | | Dale
| | |
| | | ----- Original Message -----
| | | | From: "Dale Henrichs" <[hidden email]>
| | | | To: "GemStone Seaside beta discussion"
| | | | <[hidden email]>
| | | | Sent: Thursday, April 12, 2012 3:46:52 PM
| | | | Subject: Re: [GS/SS Beta] Set session duration
| | | |
| | | | Hmmm,
| | | |
| | | | This is a new one for me ... With 1200 you should be getting a
| | | | timeout of 20 minutes.
| | | |
| | | | I've heard of sessions not getting expired soon enough[1], but
| | | | not
| | | | too soon.
| | | |
| | | | So let's start by finding out what class of expiryPolicy you
| | | | are
| | | | using. It should be an instance of WARcLastAccessExpiryPolicy.
| | | |
| | | | I assume that you must be running the maintenance vm, otherwise
| | | | the
| | | | sessions will never be expired (Issue 332), but I think it
| | | | would
| | | | be
| | | | useful to look at the log files for the you seaside servers and
| | | | your
| | | | maintenance vm ... if you could give me approximate times that
| | | | you
| | | | started each session and the approximate time that you saw the
| | | | session begin expired, we might be able to correlate what's
| | | | going
| | | | on
| | | | with information in the log ...
| | | |
| | | | Given bug 332, as a workaround you can try changing the
| | | | frequency
| | | | of
| | | | session expirations by editting WAGemStoneMaintenanceTask
| | | | class>>maintenanceTaskExpiration and change the frequency from
| | | | 1
| | | | second to 1200 seconds to match you expected expiration rate,
| | | | but
| | | | if
| | | | the bug is in the expiration logic, your sessions will expire
| | | | every
| | | | 20 minutes anyway, so it's probably not a valid workaround...
| | | |
| | | | Dale
| | | |
| | | | [1] http://code.google.com/p/glassdb/issues/detail?id=332
| | | |
| | | | ----- Original Message -----
| | | | | From: "keropotter" <[hidden email]>
| | | | | To: [hidden email]
| | | | | Sent: Thursday, April 12, 2012 1:45:37 PM
| | | | | Subject: [GS/SS Beta] Set session duration
| | | | |
| | | | | Hi!!
| | | | |
| | | | | We're on a project, about to go live. But we're experiencing
| | | | | issues
| | | | | on
| | | | | session duration.
| | | | |
| | | | | We're working with Seaside 3.0 on Gemstone 3.0.1 x64.
| | | | |
| | | | | As I've seen on the Internet, it should be enough with this
| | | | | piece
| | | | | of
| | | | | code:
| | | | |
| | | | | (WAAdmin defaultDispatcher handlers at: 'myAplicationName')
| | | | | cache
| | | | | expiryPolicy configuration at: #cacheTimeout put: 1200
| | | | |
| | | | | (to get a 10 minutes long session).
| | | | |
| | | | | This seems to be working ok on Pharo, but when we try on
| | | | | Gemstone
| | | | | and
| | | | | have
| | | | | multiple users working at the same time, the session times
| | | | | out
| | | | | at
| | | | | a
| | | | | random
| | | | | period of time, but never get to the 10 minutes we've
| | | | | configured
| | | | | de
| | | | | application for.
| | | | |
| | | | | Has anybody experienced this issue? Is there a way to solve
| | | | | this?
| | | | |
| | | | | Many thanks in advance!!
| | | | | Alejandro
| | | | |
| | | | | --
| | | | | View this message in context:
| | | | | http://forum.world.st/Set-session-duration-tp4553027p4553027.html
| | | | | Sent from the GLASS mailing list archive at Nabble.com.
| | | | |
| | | |
| | |
| |
|

keropotter

Re: Set session duration

Thank you so much, Dale!!!

We included this piece of code in our session class and are testing to see if it works for us.

Thank you very much for your help again!!

Alejandro

On Thu, Apr 12, 2012 at 9:24 PM, Dale Henrichs [via Smalltalk] <[hidden email]> wrote:

It doesn't look like there is any way to actually control the timeout used by the continuation cache without directly editing the code. The WASession>>createCache method looks like the following:

createCache
"To configure the continuation cache you must currently subclass WASession and
override this method."
^ WACache new
setExpiryPolicy: (WARcLastAccessExpiryPolicy new);
yourself.

it looks like if you change it to this:

createCache
"To configure the continuation cache you must currently subclass WASession and
override this method."

| policy |
policy := WARcLastAccessExpiryPolicy new.
policy configuration at: #cacheTimeout put: 1200.
^ WACache new
setExpiryPolicy: policy;
yourself.

you'll get both the session and continuation timeouts in synch ... this should probably get you going I would think.

Dale
----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, April 12, 2012 5:08:35 PM
| Subject: Re: [GS/SS Beta] Set session duration
|
| Okay ... I think I have a little more information for you ...
|
| When you set the expiry policy the way that you do, you are only
| setting the expiry policy for the session and not for the
| continuations created by the session ... the continuations within
| the session are still expired at the default value of 5 minutes ...
|
| so it probably isn't the session that is timing out on you, but some
| of the continuations in the session are being reaped after five
| minutes.
|
| If you change the system default expiry (not exactly sure myself how
| to do that ... probably in the application configuration panel? )
| you can effectively change the timeout for the continuations as well
| ...
|
| I will poke around a little more to see how you can do this
| programmatically ...
|
| In pharo, the expiration policy for continuations is probably a bit
| different which is why you are not seeing the same behavior on Pharo
| ...
|
| Dale
|
| ----- Original Message -----
| | From: "Dale Henrichs" <[hidden email]>
| | To: "GemStone Seaside beta discussion" <[hidden email]>
| | Sent: Thursday, April 12, 2012 4:25:36 PM
| | Subject: Re: [GS/SS Beta] Set session duration
| |
| | I just tried an experiment using the default timeout in a 3.0.1 and
| | I
| | was able to keep two active sessions alive (in two tabs in the
| | browser) while a third session in another tab expired ... I'll now
| | bump the timeout up on the different apps I'm using and see what
| | happens ...
| |
| | I guess this test involved 3 different apps ... I'll try it with
| | the
| | same app ...
| |
| | Dale
| |
| | ----- Original Message -----
| | | From: "Dale Henrichs" <[hidden email]>
| | | To: "GemStone Seaside beta discussion"
| | | <[hidden email]>
| | | Sent: Thursday, April 12, 2012 4:09:54 PM
| | | Subject: Re: [GS/SS Beta] Set session duration
| | |
| | | Are the two sessions active during this time period or are they
| | | completely inactive?
| | |
| | | Dale
| | |
| | | ----- Original Message -----
| | | | From: "Dale Henrichs" <[hidden email]>
| | | | To: "GemStone Seaside beta discussion"
| | | | <[hidden email]>
| | | | Sent: Thursday, April 12, 2012 3:46:52 PM
| | | | Subject: Re: [GS/SS Beta] Set session duration
| | | |
| | | | Hmmm,
| | | |
| | | | This is a new one for me ... With 1200 you should be getting a
| | | | timeout of 20 minutes.
| | | |
| | | | I've heard of sessions not getting expired soon enough[1], but
| | | | not
| | | | too soon.
| | | |
| | | | So let's start by finding out what class of expiryPolicy you
| | | | are
| | | | using. It should be an instance of WARcLastAccessExpiryPolicy.
| | | |
| | | | I assume that you must be running the maintenance vm, otherwise
| | | | the
| | | | sessions will never be expired (Issue 332), but I think it
| | | | would
| | | | be
| | | | useful to look at the log files for the you seaside servers and
| | | | your
| | | | maintenance vm ... if you could give me approximate times that
| | | | you
| | | | started each session and the approximate time that you saw the
| | | | session begin expired, we might be able to correlate what's
| | | | going
| | | | on
| | | | with information in the log ...
| | | |
| | | | Given bug 332, as a workaround you can try changing the
| | | | frequency
| | | | of
| | | | session expirations by editting WAGemStoneMaintenanceTask
| | | | class>>maintenanceTaskExpiration and change the frequency from
| | | | 1
| | | | second to 1200 seconds to match you expected expiration rate,
| | | | but
| | | | if
| | | | the bug is in the expiration logic, your sessions will expire
| | | | every
| | | | 20 minutes anyway, so it's probably not a valid workaround...
| | | |
| | | | Dale
| | | |
| | | | [1] http://code.google.com/p/glassdb/issues/detail?id=332
| | | |
| | | | ----- Original Message -----
| | | | | From: "keropotter" <[hidden email]>
| | | | | To: [hidden email]
| | | | | Sent: Thursday, April 12, 2012 1:45:37 PM
| | | | | Subject: [GS/SS Beta] Set session duration
| | | | |
| | | | | Hi!!
| | | | |
| | | | | We're on a project, about to go live. But we're experiencing
| | | | | issues
| | | | | on
| | | | | session duration.
| | | | |
| | | | | We're working with Seaside 3.0 on Gemstone 3.0.1 x64.
| | | | |
| | | | | As I've seen on the Internet, it should be enough with this
| | | | | piece
| | | | | of
| | | | | code:
| | | | |
| | | | | (WAAdmin defaultDispatcher handlers at: 'myAplicationName')
| | | | | cache
| | | | | expiryPolicy configuration at: #cacheTimeout put: 1200
| | | | |
| | | | | (to get a 10 minutes long session).
| | | | |
| | | | | This seems to be working ok on Pharo, but when we try on
| | | | | Gemstone
| | | | | and
| | | | | have
| | | | | multiple users working at the same time, the session times
| | | | | out
| | | | | at
| | | | | a
| | | | | random
| | | | | period of time, but never get to the 10 minutes we've
| | | | | configured
| | | | | de
| | | | | application for.
| | | | |
| | | | | Has anybody experienced this issue? Is there a way to solve
| | | | | this?
| | | | |
| | | | | Many thanks in advance!!
| | | | | Alejandro
| | | | |
| | | | | --
| | | | | View this message in context:
| | | | | http://forum.world.st/Set-session-duration-tp4553027p4553027.html
| | | | | Sent from the GLASS mailing list archive at Nabble.com.
| | | | |
| | | |
| | |
| |
|

If you reply to this email, your message will be added to the discussion below:

http://forum.world.st/Set-session-duration-tp4553027p4553447.html

To unsubscribe from Set session duration, click here.
NAML

keropotter

Re: Set session duration

In reply to this post by Dale Henrichs

Dale, we've been testing this solution for some time and it is working perfectly.

Thank you very much for your help!!!!

Alejandro

On Fri, Apr 13, 2012 at 10:27 AM, Alejandro Mehring <[hidden email]> wrote:

Thank you so much, Dale!!!

We included this piece of code in our session class and are testing to see if it works for us.

Thank you very much for your help again!!

Alejandro

On Thu, Apr 12, 2012 at 9:24 PM, Dale Henrichs [via Smalltalk] <[hidden email]> wrote:

It doesn't look like there is any way to actually control the timeout used by the continuation cache without directly editing the code. The WASession>>createCache method looks like the following:

createCache
"To configure the continuation cache you must currently subclass WASession and
override this method."
^ WACache new
setExpiryPolicy: (WARcLastAccessExpiryPolicy new);
yourself.

it looks like if you change it to this:

createCache
"To configure the continuation cache you must currently subclass WASession and
override this method."

| policy |
policy := WARcLastAccessExpiryPolicy new.
policy configuration at: #cacheTimeout put: 1200.
^ WACache new
setExpiryPolicy: policy;
yourself.

you'll get both the session and continuation timeouts in synch ... this should probably get you going I would think.

Dale
----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Thursday, April 12, 2012 5:08:35 PM
| Subject: Re: [GS/SS Beta] Set session duration
|
| Okay ... I think I have a little more information for you ...
|
| When you set the expiry policy the way that you do, you are only
| setting the expiry policy for the session and not for the
| continuations created by the session ... the continuations within
| the session are still expired at the default value of 5 minutes ...
|
| so it probably isn't the session that is timing out on you, but some
| of the continuations in the session are being reaped after five
| minutes.
|
| If you change the system default expiry (not exactly sure myself how
| to do that ... probably in the application configuration panel? )
| you can effectively change the timeout for the continuations as well
| ...
|
| I will poke around a little more to see how you can do this
| programmatically ...
|
| In pharo, the expiration policy for continuations is probably a bit
| different which is why you are not seeing the same behavior on Pharo
| ...
|
| Dale
|
| ----- Original Message -----
| | From: "Dale Henrichs" <[hidden email]>
| | To: "GemStone Seaside beta discussion" <[hidden email]>
| | Sent: Thursday, April 12, 2012 4:25:36 PM
| | Subject: Re: [GS/SS Beta] Set session duration
| |
| | I just tried an experiment using the default timeout in a 3.0.1 and
| | I
| | was able to keep two active sessions alive (in two tabs in the
| | browser) while a third session in another tab expired ... I'll now
| | bump the timeout up on the different apps I'm using and see what
| | happens ...
| |
| | I guess this test involved 3 different apps ... I'll try it with
| | the
| | same app ...
| |
| | Dale
| |
| | ----- Original Message -----
| | | From: "Dale Henrichs" <[hidden email]>
| | | To: "GemStone Seaside beta discussion"
| | | <[hidden email]>
| | | Sent: Thursday, April 12, 2012 4:09:54 PM
| | | Subject: Re: [GS/SS Beta] Set session duration
| | |
| | | Are the two sessions active during this time period or are they
| | | completely inactive?
| | |
| | | Dale
| | |
| | | ----- Original Message -----
| | | | From: "Dale Henrichs" <[hidden email]>
| | | | To: "GemStone Seaside beta discussion"
| | | | <[hidden email]>
| | | | Sent: Thursday, April 12, 2012 3:46:52 PM
| | | | Subject: Re: [GS/SS Beta] Set session duration
| | | |
| | | | Hmmm,
| | | |
| | | | This is a new one for me ... With 1200 you should be getting a
| | | | timeout of 20 minutes.
| | | |
| | | | I've heard of sessions not getting expired soon enough[1], but
| | | | not
| | | | too soon.
| | | |
| | | | So let's start by finding out what class of expiryPolicy you
| | | | are
| | | | using. It should be an instance of WARcLastAccessExpiryPolicy.
| | | |
| | | | I assume that you must be running the maintenance vm, otherwise
| | | | the
| | | | sessions will never be expired (Issue 332), but I think it
| | | | would
| | | | be
| | | | useful to look at the log files for the you seaside servers and
| | | | your
| | | | maintenance vm ... if you could give me approximate times that
| | | | you
| | | | started each session and the approximate time that you saw the
| | | | session begin expired, we might be able to correlate what's
| | | | going
| | | | on
| | | | with information in the log ...
| | | |
| | | | Given bug 332, as a workaround you can try changing the
| | | | frequency
| | | | of
| | | | session expirations by editting WAGemStoneMaintenanceTask
| | | | class>>maintenanceTaskExpiration and change the frequency from
| | | | 1
| | | | second to 1200 seconds to match you expected expiration rate,
| | | | but
| | | | if
| | | | the bug is in the expiration logic, your sessions will expire
| | | | every
| | | | 20 minutes anyway, so it's probably not a valid workaround...
| | | |
| | | | Dale
| | | |
| | | | [1] http://code.google.com/p/glassdb/issues/detail?id=332
| | | |
| | | | ----- Original Message -----
| | | | | From: "keropotter" <[hidden email]>
| | | | | To: [hidden email]
| | | | | Sent: Thursday, April 12, 2012 1:45:37 PM
| | | | | Subject: [GS/SS Beta] Set session duration
| | | | |
| | | | | Hi!!
| | | | |
| | | | | We're on a project, about to go live. But we're experiencing
| | | | | issues
| | | | | on
| | | | | session duration.
| | | | |
| | | | | We're working with Seaside 3.0 on Gemstone 3.0.1 x64.
| | | | |
| | | | | As I've seen on the Internet, it should be enough with this
| | | | | piece
| | | | | of
| | | | | code:
| | | | |
| | | | | (WAAdmin defaultDispatcher handlers at: 'myAplicationName')
| | | | | cache
| | | | | expiryPolicy configuration at: #cacheTimeout put: 1200
| | | | |
| | | | | (to get a 10 minutes long session).
| | | | |
| | | | | This seems to be working ok on Pharo, but when we try on
| | | | | Gemstone
| | | | | and
| | | | | have
| | | | | multiple users working at the same time, the session times
| | | | | out
| | | | | at
| | | | | a
| | | | | random
| | | | | period of time, but never get to the 10 minutes we've
| | | | | configured
| | | | | de
| | | | | application for.
| | | | |
| | | | | Has anybody experienced this issue? Is there a way to solve
| | | | | this?
| | | | |
| | | | | Many thanks in advance!!
| | | | | Alejandro
| | | | |
| | | | | --
| | | | | View this message in context:
| | | | | http://forum.world.st/Set-session-duration-tp4553027p4553027.html
| | | | | Sent from the GLASS mailing list archive at Nabble.com.
| | | | |
| | | |
| | |
| |
|

If you reply to this email, your message will be added to the discussion below:

http://forum.world.st/Set-session-duration-tp4553027p4553447.html

To unsubscribe from Set session duration, click here.
NAML

Philippe Marschall

Re: Set session duration

In reply to this post by Dale Henrichs

On Fri, Apr 13, 2012 at 2:23 AM, Dale Henrichs <[hidden email]> wrote:
> It doesn't look like there is any way to actually control the timeout used by the continuation cache without directly editing the code. The WASession>>createCache method looks like the following:
>

Subclassing WASession and overriding #createCache should work.

Cheers
Philippe

keropotter

Re: Set session duration

Yes, that's what Dale suggested and it worked perfectly.

Thank you!!
Ale

On Sun, Apr 22, 2012 at 10:58 AM, Philippe Marschall [via Smalltalk] <[hidden email]> wrote:

On Fri, Apr 13, 2012 at 2:23 AM, Dale Henrichs <[hidden email]> wrote:
> It doesn't look like there is any way to actually control the timeout used by the continuation cache without directly editing the code. The WASession>>createCache method looks like the following:
>

Subclassing WASession and overriding #createCache should work.

Cheers
Philippe

If you reply to this email, your message will be added to the discussion below:

http://forum.world.st/Set-session-duration-tp4553027p4578211.html

To unsubscribe from Set session duration, click here.
NAML

Mariano Martinez Peck

Re: [Glass] [GS/SS Beta] Set session duration

Hi guys,

I am reviving this old thread because I have been caught by the same problem. In my case, I wanted to expire at the same time I have defined for the app (moreover, same session class could be used in different apps with different expiration times). Also, I wanted to use the same session class for Pharo and for GemStone. So what I did was to implement:

MyWASessionSubclass >> setParent: aRequestHandler

super setParent: aRequestHandler.

continuations expiryPolicy configuration attributeAt: #cacheTimeout ifAbsent: [ ^ self ].

continuations expiryPolicy configuration attributeAt: #cacheTimeout put: (aRequestHandler cache expiryPolicy configuration at: #cacheTimeout).

I couldn't use the #initialize because at that point my app was not yet set..and I wanted to grab the timeout from there. The ugly IF is just so that it works in Pharo as well....

Now...the question is...what is this timeout of continuations? How does it impacts me as a developer? it is correct to set the same time as the app? From my tests it does seem the case, but I just wonder....

Thanks in advance,

On Mon, Apr 23, 2012 at 9:19 AM, keropotter <[hidden email]> wrote:

Yes, that's what Dale suggested and it worked perfectly.

Thank you!!
Ale

On Sun, Apr 22, 2012 at 10:58 AM, Philippe Marschall [via Smalltalk] <[hidden email]> wrote:

On Fri, Apr 13, 2012 at 2:23 AM, Dale Henrichs <[hidden email]> wrote:
> It doesn't look like there is any way to actually control the timeout used by the continuation cache without directly editing the code. The WASession>>createCache method looks like the following:
>

Subclassing WASession and overriding #createCache should work.

Cheers
Philippe

If you reply to this email, your message will be added to the discussion below:

http://forum.world.st/Set-session-duration-tp4553027p4578211.html

To unsubscribe from Set session duration, click here.
NAML

View this message in context: Re: Set session duration

Sent from the GLASS mailing list archive at Nabble.com.

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Dale Henrichs-3

Re: [Glass] [GS/SS Beta] Set session duration

Mariano,

I haven't delved into the timeouts for quite some time, so this is from memory and I could be completely wrong:).

IIRC, there are two caches that are two caches that are subject to timeouts: the session cache and "continuation cache" ... when the session is timed out, the session itself is no longer accessible ...

The "continuation cache" manages the lifetime of individual link continuations for a particular page and when a continuation is timed out that particular link is no longer accessible while the session and other links are still available ...

the mtce vm process is responsible for timing out both the session cache and continuation cache (see WABasicDevelopment class>>reapHandlerCache:dispatchers:) and the reaping is done via the message gemstoneReap ....

GemStone uses the WARcLastAccessExpiryPolicy and this should not be changed as the reduced conflict aspect is important for GemStone ... if other types of Expiry polices are needed, they just need to be made RC ... the implication of this is that timeout is used to determine expiration...

I think that standard Seaside uses a different scheme (least recently used?) for continuations and I seem to recall that a count of some kind was involved (not sure about this bit) ...

The timeout will impact links from the aspect that if a link isn't used during the timeout period it will be reaped while the session itself can continue to live as long as it has been accessed so continuations are not kept alive for the duration of a session ...

Given this information I can't think of a reason why you would need to set the timeout for continuations less than the session timeout and I don't think it makes sense to set the continuation timeout longer than the session timeout, since I don't think that old links are in danger of being accessed past the link timeout ...

Dale

On Tue, Mar 11, 2014 at 12:53 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I am reviving this old thread because I have been caught by the same problem. In my case, I wanted to expire at the same time I have defined for the app (moreover, same session class could be used in different apps with different expiration times). Also, I wanted to use the same session class for Pharo and for GemStone. So what I did was to implement:

MyWASessionSubclass >> setParent: aRequestHandler
super setParent: aRequestHandler.
continuations expiryPolicy configuration attributeAt: #cacheTimeout ifAbsent: [ ^ self ].

continuations expiryPolicy configuration attributeAt: #cacheTimeout put: (aRequestHandler cache expiryPolicy configuration at: #cacheTimeout).

I couldn't use the #initialize because at that point my app was not yet set..and I wanted to grab the timeout from there. The ugly IF is just so that it works in Pharo as well....

Now...the question is...what is this timeout of continuations? How does it impacts me as a developer? it is correct to set the same time as the app? From my tests it does seem the case, but I just wonder....

Thanks in advance,

On Mon, Apr 23, 2012 at 9:19 AM, keropotter <[hidden email]> wrote:

Yes, that's what Dale suggested and it worked perfectly.

Thank you!!
Ale

On Sun, Apr 22, 2012 at 10:58 AM, Philippe Marschall [via Smalltalk] <[hidden email]> wrote:

On Fri, Apr 13, 2012 at 2:23 AM, Dale Henrichs <[hidden email]> wrote:
> It doesn't look like there is any way to actually control the timeout used by the continuation cache without directly editing the code. The WASession>>createCache method looks like the following:
>

Subclassing WASession and overriding #createCache should work.

Cheers
Philippe

If you reply to this email, your message will be added to the discussion below:

http://forum.world.st/Set-session-duration-tp4553027p4578211.html

To unsubscribe from Set session duration, click here.
NAML

View this message in context: Re: Set session duration

Sent from the GLASS mailing list archive at Nabble.com.

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Mariano Martinez Peck

Re: [Glass] [GS/SS Beta] Set session duration

On Tue, Mar 11, 2014 at 5:38 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I haven't delved into the timeouts for quite some time, so this is from memory and I could be completely wrong:).

IIRC, there are two caches that are two caches that are subject to timeouts: the session cache and "continuation cache" ... when the session is timed out, the session itself is no longer accessible ...

The "continuation cache" manages the lifetime of individual link continuations for a particular page and when a continuation is timed out that particular link is no longer accessible while the session and other links are still available ...

the mtce vm process is responsible for timing out both the session cache and continuation cache (see WABasicDevelopment class>>reapHandlerCache:dispatchers:) and the reaping is done via the message gemstoneReap ....

GemStone uses the WARcLastAccessExpiryPolicy and this should not be changed as the reduced conflict aspect is important for GemStone ... if other types of Expiry polices are needed, they just need to be made RC ... the implication of this is that timeout is used to determine expiration...

I think that standard Seaside uses a different scheme (least recently used?) for continuations and I seem to recall that a count of some kind was involved (not sure about this bit) ...

The timeout will impact links from the aspect that if a link isn't used during the timeout period it will be reaped while the session itself can continue to live as long as it has been accessed so continuations are not kept alive for the duration of a session ...

Yes..that was what was happening to me. I had the main component of my app (the one that is present at anytime) and if I click in any menu or something then I was kickoff. But what can I do if it is not clicking or doing something?

Given this information I can't think of a reason why you would need to set the timeout for continuations less than the session timeout and I don't think it makes sense to set the continuation timeout longer than the session timeout, since I don't think that old links are in danger of being accessed past the link timeout ...

Exactly!!!! That was my reasoning too...but then I wonder why the continuations time out existed at all ;)

Thanks,

Dale

On Tue, Mar 11, 2014 at 12:53 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I am reviving this old thread because I have been caught by the same problem. In my case, I wanted to expire at the same time I have defined for the app (moreover, same session class could be used in different apps with different expiration times). Also, I wanted to use the same session class for Pharo and for GemStone. So what I did was to implement:

MyWASessionSubclass >> setParent: aRequestHandler
super setParent: aRequestHandler.
continuations expiryPolicy configuration attributeAt: #cacheTimeout ifAbsent: [ ^ self ].

continuations expiryPolicy configuration attributeAt: #cacheTimeout put: (aRequestHandler cache expiryPolicy configuration at: #cacheTimeout).

I couldn't use the #initialize because at that point my app was not yet set..and I wanted to grab the timeout from there. The ugly IF is just so that it works in Pharo as well....

Now...the question is...what is this timeout of continuations? How does it impacts me as a developer? it is correct to set the same time as the app? From my tests it does seem the case, but I just wonder....

Thanks in advance,

On Mon, Apr 23, 2012 at 9:19 AM, keropotter <[hidden email]> wrote:

Yes, that's what Dale suggested and it worked perfectly.

Thank you!!
Ale

On Sun, Apr 22, 2012 at 10:58 AM, Philippe Marschall [via Smalltalk] <[hidden email]> wrote:

On Fri, Apr 13, 2012 at 2:23 AM, Dale Henrichs <[hidden email]> wrote:
> It doesn't look like there is any way to actually control the timeout used by the continuation cache without directly editing the code. The WASession>>createCache method looks like the following:
>

Subclassing WASession and overriding #createCache should work.

Cheers
Philippe

If you reply to this email, your message will be added to the discussion below:

http://forum.world.st/Set-session-duration-tp4553027p4578211.html

To unsubscribe from Set session duration, click here.
NAML

View this message in context: Re: Set session duration

Sent from the GLASS mailing list archive at Nabble.com.

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Dale Henrichs-3

Re: [Glass] [GS/SS Beta] Set session duration

In a Pharo image the continuations could take up a lot of object memory and that can up a load on the in-memory garbage collector ...

in gemstone, since we persist session state, the in-memory garbage collector is not impacted by a "bloated" continuations cache ...

of course you end up paying the piper by having to watch your repository size and run regular MFCs ... the epoch gc can help cut down on the amount of persistent garbage created when the cache entries expire ...

Finally I think that Johan has played around with not even bothering to save the older cache entries at all ... they really only need to be saved for the back button to work and if your app is using AJAX the back button is not used ... I think...

Dale

On Tue, Mar 11, 2014 at 2:04 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Tue, Mar 11, 2014 at 5:38 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

I haven't delved into the timeouts for quite some time, so this is from memory and I could be completely wrong:).

IIRC, there are two caches that are two caches that are subject to timeouts: the session cache and "continuation cache" ... when the session is timed out, the session itself is no longer accessible ...

The "continuation cache" manages the lifetime of individual link continuations for a particular page and when a continuation is timed out that particular link is no longer accessible while the session and other links are still available ...

the mtce vm process is responsible for timing out both the session cache and continuation cache (see WABasicDevelopment class>>reapHandlerCache:dispatchers:) and the reaping is done via the message gemstoneReap ....

GemStone uses the WARcLastAccessExpiryPolicy and this should not be changed as the reduced conflict aspect is important for GemStone ... if other types of Expiry polices are needed, they just need to be made RC ... the implication of this is that timeout is used to determine expiration...

I think that standard Seaside uses a different scheme (least recently used?) for continuations and I seem to recall that a count of some kind was involved (not sure about this bit) ...

The timeout will impact links from the aspect that if a link isn't used during the timeout period it will be reaped while the session itself can continue to live as long as it has been accessed so continuations are not kept alive for the duration of a session ...

Yes..that was what was happening to me. I had the main component of my app (the one that is present at anytime) and if I click in any menu or something then I was kickoff. But what can I do if it is not clicking or doing something?

Given this information I can't think of a reason why you would need to set the timeout for continuations less than the session timeout and I don't think it makes sense to set the continuation timeout longer than the session timeout, since I don't think that old links are in danger of being accessed past the link timeout ...

Exactly!!!! That was my reasoning too...but then I wonder why the continuations time out existed at all ;)

Thanks,

Dale

On Tue, Mar 11, 2014 at 12:53 PM, Mariano Martinez Peck <[hidden email]> wrote:

Hi guys,

I am reviving this old thread because I have been caught by the same problem. In my case, I wanted to expire at the same time I have defined for the app (moreover, same session class could be used in different apps with different expiration times). Also, I wanted to use the same session class for Pharo and for GemStone. So what I did was to implement:

MyWASessionSubclass >> setParent: aRequestHandler
super setParent: aRequestHandler.
continuations expiryPolicy configuration attributeAt: #cacheTimeout ifAbsent: [ ^ self ].

continuations expiryPolicy configuration attributeAt: #cacheTimeout put: (aRequestHandler cache expiryPolicy configuration at: #cacheTimeout).

I couldn't use the #initialize because at that point my app was not yet set..and I wanted to grab the timeout from there. The ugly IF is just so that it works in Pharo as well....

Now...the question is...what is this timeout of continuations? How does it impacts me as a developer? it is correct to set the same time as the app? From my tests it does seem the case, but I just wonder....

Thanks in advance,

On Mon, Apr 23, 2012 at 9:19 AM, keropotter <[hidden email]> wrote:

Yes, that's what Dale suggested and it worked perfectly.

Thank you!!
Ale

On Sun, Apr 22, 2012 at 10:58 AM, Philippe Marschall [via Smalltalk] <[hidden email]> wrote:

On Fri, Apr 13, 2012 at 2:23 AM, Dale Henrichs <[hidden email]> wrote:
> It doesn't look like there is any way to actually control the timeout used by the continuation cache without directly editing the code. The WASession>>createCache method looks like the following:
>

Subclassing WASession and overriding #createCache should work.

Cheers
Philippe

If you reply to this email, your message will be added to the discussion below:

http://forum.world.st/Set-session-duration-tp4553027p4578211.html

To unsubscribe from Set session duration, click here.
NAML

View this message in context: Re: Set session duration

Sent from the GLASS mailing list archive at Nabble.com.

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass