Re: Page Maps and Expirations
Thanks again. I am still interested in page stores though. I'm not saying they are related to the expiration issue but I am curious how do they manage themselves. I haven't been able to find much info online. Does each one just store a potentially unlimited number of pages or is there some resource management going on? Matej Knopp-2 wrote: Hi, wicket holds the last accessed page in pagemap and certain number of previous pages in DiskPageStore (serialized on disk). The last accessed page should never be evicted from pagemap and even if it was, it would still be stored on disk. -Matej On Fri, Jan 23, 2009 at 12:19 AM, 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:
Re: Page Maps and Expirations
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-tp21610595p21610595.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
Re: Page Maps and Expirations
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-tp21610595p21610595.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 -- View this message in context: http://www.nabble.com/Page-Maps-and-Expirations-tp21610595p21612435.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
Re: Page Maps and Expirations
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-tp21610595p21610595.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 -- View this message in context: http://www.nabble.com/Page-Maps-and-Expirations-tp21610595p21612435.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
Re: Page Maps and Expirations
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
Re: Page Maps and Expirations
Hi, wicket holds the last accessed page in pagemap and certain number of previous pages in DiskPageStore (serialized on disk). The last accessed page should never be evicted from pagemap and even if it was, it would still be stored on disk. -Matej On Fri, Jan 23, 2009 at 12:19 AM, 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
Re: Page Maps and Expirations
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:
Re: Page Maps and Expirations
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
