Yes. But wicket tries to store the page being sent across cluster
during replication when the session is deserialized on target node.


On Thu, Oct 22, 2009 at 11:46 PM, Randy S. <> wrote:
> Isn't this caused by the storage of past pages in files on disk rather than
> in HTTP Session? This is in the default ISessionStore implementation (see
> SecondLevelCacheSessionStore, DiskPageStore).
> On Thu, Oct 22, 2009 at 3:27 PM, Jan Grathwohl <
>> wrote:
>> Dear all,
>> would you be so kind and share your experience about whether it is
>> reasonable to use Wicket for app development in the following situation:
>> We are planning to develop an application that will be deployed in our
>> customer's portlet environment (JBoss Portal). There will be two clustered
>> JBoss instances with JBoss's own session replication mechanism enabled. The
>> main reason for the clustering is to have failover that should be
>> transparent for logged in users, and this has to work really reliably. I
>> don't know what the exact configuration of the load balancer and the JBoss
>> servers will be, and how much influence we will have on it.
>> Is it safe to use wicket in such a situation, or should we rather go for a
>> more stateless framework?
>> I did some tests to run a very simple Wicket app in two clustered JBoss
>> instances, and after I shut down the instance with the active session, the
>> session continues to be available on the other cluster node, and the links
>> in the pages still work. So far, so good. But when I hit the browser's back
>> button, I receive a Page Expired Error. This probably means that the
>> content
>> of the page store is not correctly replicated to the other cluster node?
>> Is this a known limitation, or caused by some wrong configuration?
>> Thanks for any feedback on these topics, please let me know what your
>> experiences and opinions are.
>> Kind regards,
>> Jan

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to