In theory if websphere serializes session under stress and then deserializes back the page indeed wouldn't be restored. But it would still be in DiskPageStore, so when there is a request for that page wicket can still load. Unless Webshere sends the unbind event - which would make wicket delete the pagestore. But this doesn't seem likely - it would really be wrong behavior to send the unbind event in this case.
-Matej On Fri, Jan 23, 2009 at 12:39 AM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote: > i will let matej answer the questions below in detail. the point still > is: the last accessed page is always stored in session so the > diskstore never even comes into play if all you are doing is hitting a > submit button on a form. > > does websphere serialize sessions to disk under high load when it > starts running out of memory? if your page has a serialization problem > it wont be loaded back into memory after being spooled by websphere. > > maybe the jsession cookie is getting lost somehow? just yesterday i > got bitten by this. i had two apps running on the same domain but > different ports and one would override the session cookie of the other > whenever i would switch between them, so when i came back i would > always get a page expired error. > > you can always try upgrading to 1.3.5 and/or trunk to see if that > fixes the problem, but i doubt that is it. > > -igor > > On Thu, Jan 22, 2009 at 3:19 PM, UPBrandon <bcr...@up.com> wrote: >> >> Thanks Matej and Igor. We are using sticky sessions (I can even see the >> JSESSIONID in requests) and since a session sticks to a certain >> server/instance, there shouldn't be any need for replicating sessions among >> instances. There are dozens and dozens of web apps here and losing sessions >> hasn't been an issue. Would it make any difference if I said that sometime >> a user may get a "page expired" error only 30 seconds after the last page >> request? But this is a problem that only happens occasionally and >> supposedly under high load. >> >> Either way, I would still be interested in knowing more about how Wicket's >> session store works. >> - Under what circumstances are pages evicted from a page map? >> - Is there a limit on how many pages can be stored in a single page map? >> - Are there any "global" (per Wicket instance, not per map or session) >> limits on how many pages are held onto? >> - Under what circumstances are page maps destroyed? Only when a window or >> tab is closed? >> - Does Wicket ever destroy a session or does it let the container manage all >> that? >> >> I guess what all of those questions really get is this - is there ever a >> point where Wicket starts running out of space and has to "clean house?" If >> so, what is the process that it goes through? >> >> -Brandon >> >> >> igor.vaynberg wrote: >>> >>> yep. it looks like the servlet container is losing the session. do you >>> have sticky sessions? if not then you need to have http session >>> replication happening. >>> >>> -igor >>> >>> On Thu, Jan 22, 2009 at 1:11 PM, Matej Knopp <matej.kn...@gmail.com> >>> wrote: >>>> Well, as far as I can tell, there is nothing special going on in >>>> Wicket that might cause session expiration. Last visited page is >>>> basically a normal session property. >>>> >>>> To me this seems more likely to be servlet container / load balancer >>>> issue. >>>> >>>> -Matej >>>> >>>> On Thu, Jan 22, 2009 at 9:21 PM, UPBrandon <bcr...@up.com> wrote: >>>>> >>>>> The project I work on uses Wicket 1.3.4 and we are using the default >>>>> session >>>>> store (SecondLevelCacheSessionStore.) >>>>> >>>>> The app is clustered and runs on WebLogic 8 through Apache. I'm not >>>>> entirely sure how those two are setup but I don't believe there is any >>>>> resource sharing between instances in a cluster. Instead, when a >>>>> session is >>>>> started, a WebLogic instance is chosen and all future requests in that >>>>> session are sent to that one instance. Using that setup, there >>>>> shouldn't be >>>>> any issues with a user's request going to a machine that doesn't have >>>>> their >>>>> page map. >>>>> >>>>> The problem is happening during normal "forward" use. The example that >>>>> I >>>>> was given was a user taking a few minutes to fill out some information >>>>> and >>>>> by the time they submit the form, their session appears to have timed >>>>> out >>>>> and they get a page expired error. I hope that helps to clarify things >>>>> a >>>>> bit. >>>>> >>>>> >>>>> Matej Knopp-2 wrote: >>>>>> >>>>>> couple of questions: >>>>>> >>>>>> -what wicket version are you using? >>>>>> -are you using httpsessionstore or secondlevelcachesessionstore >>>>>> (default)? >>>>>> -what application server/container are you using? >>>>>> -are you running the application in clustered environment? if yes, >>>>>> what kind of load balancing do you have? >>>>>> -do the expirations happen during normal operation or only when using >>>>>> back button (or using application in multiple tabs) >>>>>> >>>>>> -Matej >>>>>> >>>>>> On Thu, Jan 22, 2009 at 7:47 PM, UPBrandon <bcr...@up.com> wrote: >>>>>>> >>>>>>> In some of our Wicket applications, as the number of users has started >>>>>>> to >>>>>>> ramp up, we seem to be experiencing a scalability issue. Some users >>>>>>> have >>>>>>> had problems with pages expiring quickly. This is second-hand >>>>>>> information >>>>>>> so I can't elaborate much but supposedly, during peak times, pages are >>>>>>> expiring after just a few minutes of inactivity. It would be nice to >>>>>>> be >>>>>>> able to set a minimum retention time but I don't seem to see an option >>>>>>> like >>>>>>> that. I've found information about how Wicket stores pages and >>>>>>> revisions >>>>>>> (http://cwiki.apache.org/WICKET/page-maps.html) but I haven't been >>>>>>> able >>>>>>> to >>>>>>> find much on how Wicket manages that data when things start "filling >>>>>>> up." >>> >>>>>>> Are there any good explanations out there on the web? >>>>>>> >>>>>>> -Brandon >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Page-Maps-and-Expirations-tp21610595p21615739.html >> Sent from the Wicket - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
