You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Marios Skounakis <ms...@gmail.com> on 2013/03/28 21:17:48 UTC
Wicket and tomcat cluster
Hi all,
I
'm planning to setup a terracotta tomcat cluster. The wicket site claims
that "all Wicket applications will work on a cluster automatically and
without additional work
"
.
I understand that basically since session state is kept in serializable
objects within the http session, it mostly works.
But is it true that NO changes are needed? Do I need to change any
settings? What does the page store do once it has to push a page from
memory to disk?
T
hanks in advance
Marios
Re: Wicket and tomcat cluster
Posted by Marios Skounakis <ms...@gmail.com>.
Thanks, things are a lot clearer for me now.
On Fri, Mar 29, 2013 at 4:28 PM, Dan Retzlaff <dr...@gmail.com> wrote:
> If you go non-sticky you'll need to experiment with RenderStrategy. Each
> has it's pros and cons, and I don't have experience to advise you further.
>
> Yes if you want the user to interact with more than one page at a time
> you'll need to make sure they're all available. You'll also need to
> replicate synchronously to all nodes.
>
> Since Wicket is a stateful framework, it's simply not well-suited to
> nonsticky deployment IMO, and you should just enable stickiness. In the off
> chance of a server failure user loses some page history, but at least they
> stay logged in and don't lose their current activity.
>
> I've wondered at possibility of replication listener on failover nodes that
> maintains complete local disk page store. Not sure if/which containers
> provide such hooks.
>
> Dan
> On Mar 29, 2013 1:06 AM, "Marios Skounakis" <ms...@gmail.com> wrote:
>
> > Dan, thanks for you answer.
> >
> > As you said, with the default implementation of DiskDataStore only the
> most
> > recent page is kept in the session state and available on all servers. So
> > are using non-sticky sessions and having a stateful page open a modal
> > window with a new stateful page will not work. Correct?
> >
> >
> >
> > On Thu, Mar 28, 2013 at 10:37 PM, Dan Retzlaff <dr...@gmail.com>
> > wrote:
> >
> > > Sorry I mistyped: default is REDIRECT_TO_BUFFER.
> > >
> > > On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff <dr...@gmail.com>
> > wrote:
> > >
> > > > Hi Marios,
> > > >
> > > > This behavior is determined by IDataStore interface. DiskDataStore is
> > > used
> > > > by default, so only the most recent page is kept in the session (and
> > > > available for failover). It puts page history into a directory
> > specified
> > > in
> > > > "javax.servlet.context.tempdir" servlet attribute (under "work"
> > directory
> > > > in Tomcat). If you want more page history available on failover,
> > specify
> > > a
> > > > IPageManagerProvider in your Application#init() that constructs
> > > > HttpSessionDataStore instead. Note HttpSessionDataStore's
> > > > IDataStoreEvictionStrategy dependency which keeps session usage under
> > > > control.
> > > >
> > > > If Wicket clustering is new to you, also note that Wicket
> > > > uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for
> > > details,
> > > > but in short: you should configure your load balancer for sticky
> > > sessions.
> > > >
> > > > Dan
> > > >
> > > > On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis <mscoon@gmail.com
> > > >wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> I
> > > >> 'm planning to setup a terracotta tomcat cluster. The wicket site
> > claims
> > > >> that "all Wicket applications will work on a cluster automatically
> and
> > > >> without additional work
> > > >> "
> > > >> .
> > > >>
> > > >> I understand that basically since session state is kept in
> > serializable
> > > >> objects within the http session, it mostly works.
> > > >>
> > > >> But is it true that NO changes are needed? Do I need to change any
> > > >> settings? What does the page store do once it has to push a page
> from
> > > >> memory to disk?
> > > >>
> > > >>
> > > >> T
> > > >> hanks in advance
> > > >> Marios
> > > >>
> > > >
> > > >
> > >
> >
>
Re: Wicket and tomcat cluster
Posted by Dan Retzlaff <dr...@gmail.com>.
If you go non-sticky you'll need to experiment with RenderStrategy. Each
has it's pros and cons, and I don't have experience to advise you further.
Yes if you want the user to interact with more than one page at a time
you'll need to make sure they're all available. You'll also need to
replicate synchronously to all nodes.
Since Wicket is a stateful framework, it's simply not well-suited to
nonsticky deployment IMO, and you should just enable stickiness. In the off
chance of a server failure user loses some page history, but at least they
stay logged in and don't lose their current activity.
I've wondered at possibility of replication listener on failover nodes that
maintains complete local disk page store. Not sure if/which containers
provide such hooks.
Dan
On Mar 29, 2013 1:06 AM, "Marios Skounakis" <ms...@gmail.com> wrote:
> Dan, thanks for you answer.
>
> As you said, with the default implementation of DiskDataStore only the most
> recent page is kept in the session state and available on all servers. So
> are using non-sticky sessions and having a stateful page open a modal
> window with a new stateful page will not work. Correct?
>
>
>
> On Thu, Mar 28, 2013 at 10:37 PM, Dan Retzlaff <dr...@gmail.com>
> wrote:
>
> > Sorry I mistyped: default is REDIRECT_TO_BUFFER.
> >
> > On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff <dr...@gmail.com>
> wrote:
> >
> > > Hi Marios,
> > >
> > > This behavior is determined by IDataStore interface. DiskDataStore is
> > used
> > > by default, so only the most recent page is kept in the session (and
> > > available for failover). It puts page history into a directory
> specified
> > in
> > > "javax.servlet.context.tempdir" servlet attribute (under "work"
> directory
> > > in Tomcat). If you want more page history available on failover,
> specify
> > a
> > > IPageManagerProvider in your Application#init() that constructs
> > > HttpSessionDataStore instead. Note HttpSessionDataStore's
> > > IDataStoreEvictionStrategy dependency which keeps session usage under
> > > control.
> > >
> > > If Wicket clustering is new to you, also note that Wicket
> > > uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for
> > details,
> > > but in short: you should configure your load balancer for sticky
> > sessions.
> > >
> > > Dan
> > >
> > > On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis <mscoon@gmail.com
> > >wrote:
> > >
> > >> Hi all,
> > >>
> > >> I
> > >> 'm planning to setup a terracotta tomcat cluster. The wicket site
> claims
> > >> that "all Wicket applications will work on a cluster automatically and
> > >> without additional work
> > >> "
> > >> .
> > >>
> > >> I understand that basically since session state is kept in
> serializable
> > >> objects within the http session, it mostly works.
> > >>
> > >> But is it true that NO changes are needed? Do I need to change any
> > >> settings? What does the page store do once it has to push a page from
> > >> memory to disk?
> > >>
> > >>
> > >> T
> > >> hanks in advance
> > >> Marios
> > >>
> > >
> > >
> >
>
Re: Wicket and tomcat cluster
Posted by Marios Skounakis <ms...@gmail.com>.
Dan, thanks for you answer.
As you said, with the default implementation of DiskDataStore only the most
recent page is kept in the session state and available on all servers. So
are using non-sticky sessions and having a stateful page open a modal
window with a new stateful page will not work. Correct?
On Thu, Mar 28, 2013 at 10:37 PM, Dan Retzlaff <dr...@gmail.com> wrote:
> Sorry I mistyped: default is REDIRECT_TO_BUFFER.
>
> On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff <dr...@gmail.com> wrote:
>
> > Hi Marios,
> >
> > This behavior is determined by IDataStore interface. DiskDataStore is
> used
> > by default, so only the most recent page is kept in the session (and
> > available for failover). It puts page history into a directory specified
> in
> > "javax.servlet.context.tempdir" servlet attribute (under "work" directory
> > in Tomcat). If you want more page history available on failover, specify
> a
> > IPageManagerProvider in your Application#init() that constructs
> > HttpSessionDataStore instead. Note HttpSessionDataStore's
> > IDataStoreEvictionStrategy dependency which keeps session usage under
> > control.
> >
> > If Wicket clustering is new to you, also note that Wicket
> > uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for
> details,
> > but in short: you should configure your load balancer for sticky
> sessions.
> >
> > Dan
> >
> > On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis <mscoon@gmail.com
> >wrote:
> >
> >> Hi all,
> >>
> >> I
> >> 'm planning to setup a terracotta tomcat cluster. The wicket site claims
> >> that "all Wicket applications will work on a cluster automatically and
> >> without additional work
> >> "
> >> .
> >>
> >> I understand that basically since session state is kept in serializable
> >> objects within the http session, it mostly works.
> >>
> >> But is it true that NO changes are needed? Do I need to change any
> >> settings? What does the page store do once it has to push a page from
> >> memory to disk?
> >>
> >>
> >> T
> >> hanks in advance
> >> Marios
> >>
> >
> >
>
Re: Wicket and tomcat cluster
Posted by Dan Retzlaff <dr...@gmail.com>.
Sorry I mistyped: default is REDIRECT_TO_BUFFER.
On Thu, Mar 28, 2013 at 2:36 PM, Dan Retzlaff <dr...@gmail.com> wrote:
> Hi Marios,
>
> This behavior is determined by IDataStore interface. DiskDataStore is used
> by default, so only the most recent page is kept in the session (and
> available for failover). It puts page history into a directory specified in
> "javax.servlet.context.tempdir" servlet attribute (under "work" directory
> in Tomcat). If you want more page history available on failover, specify a
> IPageManagerProvider in your Application#init() that constructs
> HttpSessionDataStore instead. Note HttpSessionDataStore's
> IDataStoreEvictionStrategy dependency which keeps session usage under
> control.
>
> If Wicket clustering is new to you, also note that Wicket
> uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for details,
> but in short: you should configure your load balancer for sticky sessions.
>
> Dan
>
> On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis <ms...@gmail.com>wrote:
>
>> Hi all,
>>
>> I
>> 'm planning to setup a terracotta tomcat cluster. The wicket site claims
>> that "all Wicket applications will work on a cluster automatically and
>> without additional work
>> "
>> .
>>
>> I understand that basically since session state is kept in serializable
>> objects within the http session, it mostly works.
>>
>> But is it true that NO changes are needed? Do I need to change any
>> settings? What does the page store do once it has to push a page from
>> memory to disk?
>>
>>
>> T
>> hanks in advance
>> Marios
>>
>
>
Re: Wicket and tomcat cluster
Posted by Dan Retzlaff <dr...@gmail.com>.
Hi Marios,
This behavior is determined by IDataStore interface. DiskDataStore is used
by default, so only the most recent page is kept in the session (and
available for failover). It puts page history into a directory specified in
"javax.servlet.context.tempdir" servlet attribute (under "work" directory
in Tomcat). If you want more page history available on failover, specify a
IPageManagerProvider in your Application#init() that constructs
HttpSessionDataStore instead. Note HttpSessionDataStore's
IDataStoreEvictionStrategy dependency which keeps session usage under
control.
If Wicket clustering is new to you, also note that Wicket
uses RenderStrategy.REDIRECT_TO_RENDER by default. See javadoc for details,
but in short: you should configure your load balancer for sticky sessions.
Dan
On Thu, Mar 28, 2013 at 2:17 PM, Marios Skounakis <ms...@gmail.com> wrote:
> Hi all,
>
> I
> 'm planning to setup a terracotta tomcat cluster. The wicket site claims
> that "all Wicket applications will work on a cluster automatically and
> without additional work
> "
> .
>
> I understand that basically since session state is kept in serializable
> objects within the http session, it mostly works.
>
> But is it true that NO changes are needed? Do I need to change any
> settings? What does the page store do once it has to push a page from
> memory to disk?
>
>
> T
> hanks in advance
> Marios
>