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
