Multiple Browser Tabs on Same Application
Locked
 
|
We've had some users complain of "session timeouts" on our GLASS application. After looking into it, I see that their sessions aren't timing out, but they are being pushed to the root component due to (what looks like) continuation cache expiration.
The users who complained all had the same mode of operation. At some point, they opened a new browser tab within the same session, navigated around in the new tab for a while, and then returned to the old tab. They click a link on the old tab, and instead of seeing what they expected -- they get kicked out to the root. Apparently the continuation for the old page has been removed from the cache. What's the best solution for this? I confess that my knowledge of the continuation internals is sketchy, but some ideas are: 1. Use the Ramon/Lukas Ajax "ping" [1] to keep the page alive. We're already doing this to keep sessions alive, but we could ramp up its frequency. Downside is a lot of extra chatter between the browser and the server over the life of the session. 2. Simply don't expire things from the cache (we're on Seaside 2.8, but I could replace the WALRUCache with a custom, Dictionary-like object that doesn't do expiry). We're on GemStone, so we could store continuations forever and use long session timeouts. Downside is the extra repository space required, since we're still on the 4GB free version of GemStone. And the engineer in me is turned off by the idea of storing all of that when it's mostly garbage. 3. Use bookmarkable URLs everywhere, so a request that's handled via unknownRequest: still gets the job done. The downside here is the extra work for that (updateUrl: in components, extraPath: in all links, etc). Maybe I've been spoiled by using Seaside too long -- I don't want to name my URLs if I don't have to! I might be able to blend these approaches; maybe ramp up the frequency of the Ajax ping slightly, increase the size of the cache, and use bookmarkable URLs for a few of the higher-level components so at least if you get "kicked out" you're somewhere close to where you wanted to be. * Any other/better options? * Is the situation similar/better in Seaside 3.0? Thanks, -- Ken Treis Miriam Technologies, Inc. [1] html script: (html request every: (self preferenceAt: #sessionExpirySeconds) - 60)_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Multiple Browser Tabs on Same Application
|
|
I use the ping. Easy to implement and the extra requests aren't an
interesting issue to dramatize about A bit of url stuff plus cookies won't hurt best sebastian On 03/12/2009, at 17:32, Ken Treis <[hidden email]> wrote: > We've had some users complain of "session timeouts" on our GLASS > application. After looking into it, I see that their sessions aren't > timing out, but they are being pushed to the root component due to > (what looks like) continuation cache expiration. > > The users who complained all had the same mode of operation. At some > point, they opened a new browser tab within the same session, > navigated around in the new tab for a while, and then returned to > the old tab. They click a link on the old tab, and instead of seeing > what they expected -- they get kicked out to the root. Apparently > the continuation for the old page has been removed from the cache. > > What's the best solution for this? I confess that my knowledge of > the continuation internals is sketchy, but some ideas are: > > 1. Use the Ramon/Lukas Ajax "ping" [1] to keep the page alive. We're > already doing this to keep sessions alive, but we could ramp up its > frequency. Downside is a lot of extra chatter between the browser > and the server over the life of the session. > > 2. Simply don't expire things from the cache (we're on Seaside 2.8, > but I could replace the WALRUCache with a custom, Dictionary-like > object that doesn't do expiry). We're on GemStone, so we could store > continuations forever and use long session timeouts. Downside is the > extra repository space required, since we're still on the 4GB free > version of GemStone. And the engineer in me is turned off by the > idea of storing all of that when it's mostly garbage. > > 3. Use bookmarkable URLs everywhere, so a request that's handled via > unknownRequest: still gets the job done. The downside here is the > extra work for that (updateUrl: in components, extraPath: in all > links, etc). Maybe I've been spoiled by using Seaside too long -- I > don't want to name my URLs if I don't have to! > > I might be able to blend these approaches; maybe ramp up the > frequency of the Ajax ping slightly, increase the size of the cache, > and use bookmarkable URLs for a few of the higher-level components > so at least if you get "kicked out" you're somewhere close to where > you wanted to be. > > * Any other/better options? > * Is the situation similar/better in Seaside 3.0? > > Thanks, > > -- > Ken Treis > Miriam Technologies, Inc. > > [1] html script: (html request every: (self preferenceAt: > #sessionExpirySeconds) - 60) > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Multiple Browser Tabs on Same Application
|
|
In reply to this post by Ken Treis
2009/12/3 Ken Treis <[hidden email]>:
> We've had some users complain of "session timeouts" on our GLASS application. After looking into it, I see that their sessions aren't timing out, but they are being pushed to the root component due to (what looks like) continuation cache expiration. > > The users who complained all had the same mode of operation. At some point, they opened a new browser tab within the same session, navigated around in the new tab for a while, and then returned to the old tab. They click a link on the old tab, and instead of seeing what they expected -- they get kicked out to the root. Apparently the continuation for the old page has been removed from the cache. The basic problem is this: Seaside only keeps a fixed amount of continuations for each session. The amount of continuations determines the number of steps you can go back into the browser. Clicking a link in the old tab is basically the same has hitting the back button until your in that state and then clicking the link. > What's the best solution for this? I confess that my knowledge of the continuation internals is sketchy, but some ideas are: > > 1. Use the Ramon/Lukas Ajax "ping" [1] to keep the page alive. We're already doing this to keep sessions alive, but we could ramp up its frequency. Downside is a lot of extra chatter between the browser and the server over the life of the session. I don't think this solves your problem. Keep in mind that the ping works together with the session timeout. If you session timeout is 30 min you should ping about every 25min or so. More frequently doesn't change anything. > 2. Simply don't expire things from the cache (we're on Seaside 2.8, but I could replace the WALRUCache with a custom, Dictionary-like object that doesn't do expiry). We're on GemStone, so we could store continuations forever and use long session timeouts. Downside is the extra repository space required, since we're still on the 4GB free version of GemStone. And the engineer in me is turned off by the idea of storing all of that when it's mostly garbage. I would rather increase the session timeout and the cache size so that it matches the behavior of your users. On the other hand Dale might be looking for testers for his one-gem-per-session pony ;-) > 3. Use bookmarkable URLs everywhere, so a request that's handled via unknownRequest: still gets the job done. The downside here is the extra work for that (updateUrl: in components, extraPath: in all links, etc). Maybe I've been spoiled by using Seaside too long -- I don't want to name my URLs if I don't have to! IMHO this gives away one of the biggest advantages of Seaside, not having to care about the URL. > I might be able to blend these approaches; maybe ramp up the frequency of the Ajax ping slightly, increase the size of the cache, and use bookmarkable URLs for a few of the higher-level components so at least if you get "kicked out" you're somewhere close to where you wanted to be. > > * Any other/better options? > * Is the situation similar/better in Seaside 3.0? Seaside 3.0 uses fewer continuations so the same cache size should get out farther. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Multiple Browser Tabs on Same Application
|
|
Does it make sense to be able to configure the size of the cache?
-Carl Gundel http://www.runbasic.com Easy Web Programming On Thu, Dec 3, 2009 at 4:24 PM, Philippe Marschall <[hidden email]> wrote: >> The users who complained all had the same mode of operation. At some point, they opened a new browser tab within the same session, navigated around in the new tab for a while, and then returned to the old tab. They click a link on the old tab, and instead of seeing what they expected -- they get kicked out to the root. Apparently the continuation for the old page has been removed from the cache. > > The basic problem is this: > Seaside only keeps a fixed amount of continuations for each session. > The amount of continuations determines the number of steps you can go > back into the browser. Clicking a link in the old tab is basically the > same has hitting the back button until your in that state and then > clicking the link. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Philippe Marschall
On Dec 3, 2009, at 1:24 PM, Philippe Marschall wrote:
>> 1. Use the Ramon/Lukas Ajax "ping" [1] to keep the page alive. We're already doing this to keep sessions alive, but we could ramp up its frequency. Downside is a lot of extra chatter between the browser and the server over the life of the session. > > I don't think this solves your problem. Keep in mind that the ping > works together with the session timeout. If you session timeout is 30 > min you should ping about every 25min or so. More frequently doesn't > change anything. That's interesting. Doesn't the ping update the the age table in cache, thus making sure that the continuation stays around? It seems like one ping per tab would keep each tab's original rendering context continuation alive. The ping would have to run more frequently to be useful in this regard, but then it would serve two purposes -- keeping the session alive, and keeping the continuation for that page near the top of the cache. Or am I missing something? Again, I'm on 2.8 -- maybe this is different in 3.0. -- Ken Treis Miriam Technologies, Inc. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Multiple Browser Tabs on Same Application
|
|
2009/12/4 Ken Treis <[hidden email]>:
> On Dec 3, 2009, at 1:24 PM, Philippe Marschall wrote: > >>> 1. Use the Ramon/Lukas Ajax "ping" [1] to keep the page alive. We're already doing this to keep sessions alive, but we could ramp up its frequency. Downside is a lot of extra chatter between the browser and the server over the life of the session. >> >> I don't think this solves your problem. Keep in mind that the ping >> works together with the session timeout. If you session timeout is 30 >> min you should ping about every 25min or so. More frequently doesn't >> change anything. > > That's interesting. Doesn't the ping update the the age table in cache, thus making sure that the continuation stays around? It seems like one ping per tab would keep each tab's original rendering context continuation alive. The ping would have to run more frequently to be useful in this regard, but then it would serve two purposes -- keeping the session alive, and keeping the continuation for that page near the top of the cache. > > Or am I missing something? No, you're right. But then there would be a "gap" in the continuations stored between the new and the old tab. They'll no longer be able to use back button all the way to the old tab, some of those pages will still display a session expired. Your users are using the back button more often than the default settings anticipated so I'd change the settings. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
On Dec 3, 2009, at 9:58 PM, Philippe Marschall wrote:
> No, you're right. But then there would be a "gap" in the continuations > stored between the new and the old tab. They'll no longer be able to > use back button all the way to the old tab, some of those pages will > still display a session expired. Your users are using the back button > more often than the default settings anticipated so I'd change the > settings. OK, I see what you were saying now. For now I've increased the depth of the cache (capacity: 100) and increased the Ajax ping frequency (once every 5 minutes). Based on what I'm seeing, I don't think the gap will be a problem. Thanks again, -- Ken Treis Miriam Technologies, Inc. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Multiple Browser Tabs on Same Application
|
|
Ken Treis wrote:
> OK, I see what you were saying now. For now I've increased the depth of the cache (capacity: 100) and increased the Ajax ping frequency (once every 5 minutes). Based on what I'm seeing, I don't think the gap will be a problem. > > Thanks again, Dang, I liked it better when you called it the Ramon/Lukas Ajax ping! -- Ramon Leon http://onsmalltalk.com _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |