You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Douglas Ferguson <do...@douglasferguson.us> on 2010/03/05 19:02:45 UTC
tomcat session replication
Has anybody had success with wicket using tomcat's session replication?
D/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by "sauli.ketola" <sa...@mbnet.fi>.
Dan Retzlaff wrote
> Alternatively, Tomcat 7 supports
> parallel deployments so theoretically you can upgrade in-place [1].
> [1]
> http://www.tomcatexpert.com/blog/2011/05/31/parallel-deployment-tomcat-7
Wow, I didn't know Tomcat had that feature. That could be the solution, I
need to try it out. Thanks!
-Sauli
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/tomcat-session-replication-tp1891781p4657600.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Dan Retzlaff <dr...@gmail.com>.
Hi, Sauli.
The context of your question is not clear to me. Are you trying to upgrade
a running cluster?
I have not used Nginx, but Apache HTTPD allows you to disable balancer
members from receiving new sessions. Alternatively, Tomcat 7 supports
parallel deployments so theoretically you can upgrade in-place [1]. In any
case, my understanding is that the main risk to abruptly taking a node down
is that the new node won't have users' page history (in DiskDataStore). His
current page and session state will however be available.
Any confirmation or correction of these statements from the community would
be appreciated.
Dan
[1] http://www.tomcatexpert.com/blog/2011/05/31/parallel-deployment-tomcat-7
On Wed, Mar 27, 2013 at 7:50 AM, sauli.ketola <sa...@mbnet.fi> wrote:
> Igor Vaynberg-2 wrote
> > ..the loadbalancer is
> > configured to only send new sessions to A while B is being "starved"
> > of new sessions.
>
> I know this is an old thread but I found it just now when facing a similar
> case.
> Could you or someone explain more: How do you do this and what load
> balancer
> are you using for this? Do you know would nginx support this?
>
> I would guess that it would be pretty common to have to wait for sessions
> to
> die before starting to install the server but it seems to be pretty hard to
> find any concrete examples.
>
> If someone could point me to the right direction, I'd appreciate it.
>
> -Sauli
>
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/tomcat-session-replication-tp1891781p4657571.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: tomcat session replication
Posted by "sauli.ketola" <sa...@mbnet.fi>.
Igor Vaynberg-2 wrote
> ..the loadbalancer is
> configured to only send new sessions to A while B is being "starved"
> of new sessions.
I know this is an old thread but I found it just now when facing a similar
case.
Could you or someone explain more: How do you do this and what load balancer
are you using for this? Do you know would nginx support this?
I would guess that it would be pretty common to have to wait for sessions to
die before starting to install the server but it seems to be pretty hard to
find any concrete examples.
If someone could point me to the right direction, I'd appreciate it.
-Sauli
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/tomcat-session-replication-tp1891781p4657571.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Igor Vaynberg <ig...@gmail.com>.
this problem effects any webapp that uses the http session. usually
this is handled the following way
lets say you have two nodes A and B
when starting an upgrade node A is taken offline and all sessions are
migrated to B
node A is then upgraded and brought back up with the loadbalancer is
configured to only send new sessions to A while B is being "starved"
of new sessions. once all sessions on B are expired B is taken offline
and upgraded at which point it is returned into rotation.
-igor
On Sun, Mar 7, 2010 at 4:10 PM, Douglas Ferguson
<do...@douglasferguson.us> wrote:
> Hmm.. yeah.. that even seems like it could not be fool proof.
>
> I.E. Wicket checks that components are serializable not Externalizable.
>
> I'm curious if anybody that is running wicket in a cluster has experienced this, or how you deal with deploying changes to the signature of a component.
>
> D/
>
>
>
> On Mar 7, 2010, at 2:42 PM, James Carman wrote:
>
>> You can implement Externalizable and manage it all yourself.
>>
>> On Sun, Mar 7, 2010 at 3:39 PM, Douglas Ferguson
>> <do...@douglasferguson.us> wrote:
>>> How do you prevent developers from renaming fields on components.
>>> That seems really dangerous.
>>>
>>> i.e. what seems like a simple refactor to correct a spelling mistake could result in sessions not being deserialized.
>>>
>>> D/
>>>
>>> On Mar 6, 2010, at 11:10 AM, Igor Vaynberg wrote:
>>>
>>>> not with java serialization afaik
>>>>
>>>> -igor
>>>>
>>>> On Sat, Mar 6, 2010 at 6:52 AM, Douglas Ferguson
>>>> <do...@douglasferguson.us> wrote:
>>>>> I can't deal with removing fields or changing method signatures/implementations?
>>>>>
>>>>> D/
>>>>>
>>>>> On Mar 6, 2010, at 12:58 AM, Igor Vaynberg wrote:
>>>>>
>>>>>> as long as all you do is add fields you are ok...
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Fri, Mar 5, 2010 at 8:16 PM, Douglas Ferguson
>>>>>> <do...@douglasferguson.us> wrote:
>>>>>>> So as long as the serial I'd is the same the classlader won't care the
>>>>>>> fields don't match?
>>>>>>>
>>>>>>> Douglas Ferguson
>>>>>>> 512-293-7279
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <ig...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> in the wicket code we override serial ids to 1, you should do the same
>>>>>>>> in your code.
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
>>>>>>>> <do...@douglasferguson.us> wrote:
>>>>>>>>> I'm considering a 0 downtime deployment but am concerned with the
>>>>>>>>> amount of state in the wicket session.
>>>>>>>>>
>>>>>>>>> This is the scenario that concerns me.
>>>>>>>>>
>>>>>>>>> 1) There are 2 tomcats running
>>>>>>>>> 2) A change is made to a serializable object and the serial version
>>>>>>>>> id is updated
>>>>>>>>> 3) 1 tomcat instance is taken down for updating
>>>>>>>>> 4) tomcat instance comes back up with new object and now tries to
>>>>>>>>> update state from other tomcat and the wicket session has a
>>>>>>>>> reference to the old version of the serializable.
>>>>>>>>>
>>>>>>>>> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
>>>>>>>>>
>>>>>>>>>> yes
>>>>>>>>>>
>>>>>>>>>> -igor
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
>>>>>>>>>> <do...@douglasferguson.us> wrote:
>>>>>>>>>>> Has anybody had success with wicket using tomcat's session
>>>>>>>>>>> replication?
>>>>>>>>>>>
>>>>>>>>>>> D/
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Douglas Ferguson <do...@douglasferguson.us>.
Hmm.. yeah.. that even seems like it could not be fool proof.
I.E. Wicket checks that components are serializable not Externalizable.
I'm curious if anybody that is running wicket in a cluster has experienced this, or how you deal with deploying changes to the signature of a component.
D/
On Mar 7, 2010, at 2:42 PM, James Carman wrote:
> You can implement Externalizable and manage it all yourself.
>
> On Sun, Mar 7, 2010 at 3:39 PM, Douglas Ferguson
> <do...@douglasferguson.us> wrote:
>> How do you prevent developers from renaming fields on components.
>> That seems really dangerous.
>>
>> i.e. what seems like a simple refactor to correct a spelling mistake could result in sessions not being deserialized.
>>
>> D/
>>
>> On Mar 6, 2010, at 11:10 AM, Igor Vaynberg wrote:
>>
>>> not with java serialization afaik
>>>
>>> -igor
>>>
>>> On Sat, Mar 6, 2010 at 6:52 AM, Douglas Ferguson
>>> <do...@douglasferguson.us> wrote:
>>>> I can't deal with removing fields or changing method signatures/implementations?
>>>>
>>>> D/
>>>>
>>>> On Mar 6, 2010, at 12:58 AM, Igor Vaynberg wrote:
>>>>
>>>>> as long as all you do is add fields you are ok...
>>>>>
>>>>> -igor
>>>>>
>>>>> On Fri, Mar 5, 2010 at 8:16 PM, Douglas Ferguson
>>>>> <do...@douglasferguson.us> wrote:
>>>>>> So as long as the serial I'd is the same the classlader won't care the
>>>>>> fields don't match?
>>>>>>
>>>>>> Douglas Ferguson
>>>>>> 512-293-7279
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <ig...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> in the wicket code we override serial ids to 1, you should do the same
>>>>>>> in your code.
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
>>>>>>> <do...@douglasferguson.us> wrote:
>>>>>>>> I'm considering a 0 downtime deployment but am concerned with the
>>>>>>>> amount of state in the wicket session.
>>>>>>>>
>>>>>>>> This is the scenario that concerns me.
>>>>>>>>
>>>>>>>> 1) There are 2 tomcats running
>>>>>>>> 2) A change is made to a serializable object and the serial version
>>>>>>>> id is updated
>>>>>>>> 3) 1 tomcat instance is taken down for updating
>>>>>>>> 4) tomcat instance comes back up with new object and now tries to
>>>>>>>> update state from other tomcat and the wicket session has a
>>>>>>>> reference to the old version of the serializable.
>>>>>>>>
>>>>>>>> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
>>>>>>>>
>>>>>>>>> yes
>>>>>>>>>
>>>>>>>>> -igor
>>>>>>>>>
>>>>>>>>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
>>>>>>>>> <do...@douglasferguson.us> wrote:
>>>>>>>>>> Has anybody had success with wicket using tomcat's session
>>>>>>>>>> replication?
>>>>>>>>>>
>>>>>>>>>> D/
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by James Carman <jc...@carmanconsulting.com>.
You can implement Externalizable and manage it all yourself.
On Sun, Mar 7, 2010 at 3:39 PM, Douglas Ferguson
<do...@douglasferguson.us> wrote:
> How do you prevent developers from renaming fields on components.
> That seems really dangerous.
>
> i.e. what seems like a simple refactor to correct a spelling mistake could result in sessions not being deserialized.
>
> D/
>
> On Mar 6, 2010, at 11:10 AM, Igor Vaynberg wrote:
>
>> not with java serialization afaik
>>
>> -igor
>>
>> On Sat, Mar 6, 2010 at 6:52 AM, Douglas Ferguson
>> <do...@douglasferguson.us> wrote:
>>> I can't deal with removing fields or changing method signatures/implementations?
>>>
>>> D/
>>>
>>> On Mar 6, 2010, at 12:58 AM, Igor Vaynberg wrote:
>>>
>>>> as long as all you do is add fields you are ok...
>>>>
>>>> -igor
>>>>
>>>> On Fri, Mar 5, 2010 at 8:16 PM, Douglas Ferguson
>>>> <do...@douglasferguson.us> wrote:
>>>>> So as long as the serial I'd is the same the classlader won't care the
>>>>> fields don't match?
>>>>>
>>>>> Douglas Ferguson
>>>>> 512-293-7279
>>>>> Sent from my iPhone
>>>>>
>>>>> On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <ig...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> in the wicket code we override serial ids to 1, you should do the same
>>>>>> in your code.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
>>>>>> <do...@douglasferguson.us> wrote:
>>>>>>> I'm considering a 0 downtime deployment but am concerned with the
>>>>>>> amount of state in the wicket session.
>>>>>>>
>>>>>>> This is the scenario that concerns me.
>>>>>>>
>>>>>>> 1) There are 2 tomcats running
>>>>>>> 2) A change is made to a serializable object and the serial version
>>>>>>> id is updated
>>>>>>> 3) 1 tomcat instance is taken down for updating
>>>>>>> 4) tomcat instance comes back up with new object and now tries to
>>>>>>> update state from other tomcat and the wicket session has a
>>>>>>> reference to the old version of the serializable.
>>>>>>>
>>>>>>> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
>>>>>>>
>>>>>>>> yes
>>>>>>>>
>>>>>>>> -igor
>>>>>>>>
>>>>>>>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
>>>>>>>> <do...@douglasferguson.us> wrote:
>>>>>>>>> Has anybody had success with wicket using tomcat's session
>>>>>>>>> replication?
>>>>>>>>>
>>>>>>>>> D/
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> ------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Douglas Ferguson <do...@douglasferguson.us>.
How do you prevent developers from renaming fields on components.
That seems really dangerous.
i.e. what seems like a simple refactor to correct a spelling mistake could result in sessions not being deserialized.
D/
On Mar 6, 2010, at 11:10 AM, Igor Vaynberg wrote:
> not with java serialization afaik
>
> -igor
>
> On Sat, Mar 6, 2010 at 6:52 AM, Douglas Ferguson
> <do...@douglasferguson.us> wrote:
>> I can't deal with removing fields or changing method signatures/implementations?
>>
>> D/
>>
>> On Mar 6, 2010, at 12:58 AM, Igor Vaynberg wrote:
>>
>>> as long as all you do is add fields you are ok...
>>>
>>> -igor
>>>
>>> On Fri, Mar 5, 2010 at 8:16 PM, Douglas Ferguson
>>> <do...@douglasferguson.us> wrote:
>>>> So as long as the serial I'd is the same the classlader won't care the
>>>> fields don't match?
>>>>
>>>> Douglas Ferguson
>>>> 512-293-7279
>>>> Sent from my iPhone
>>>>
>>>> On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <ig...@gmail.com>
>>>> wrote:
>>>>
>>>>> in the wicket code we override serial ids to 1, you should do the same
>>>>> in your code.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
>>>>> <do...@douglasferguson.us> wrote:
>>>>>> I'm considering a 0 downtime deployment but am concerned with the
>>>>>> amount of state in the wicket session.
>>>>>>
>>>>>> This is the scenario that concerns me.
>>>>>>
>>>>>> 1) There are 2 tomcats running
>>>>>> 2) A change is made to a serializable object and the serial version
>>>>>> id is updated
>>>>>> 3) 1 tomcat instance is taken down for updating
>>>>>> 4) tomcat instance comes back up with new object and now tries to
>>>>>> update state from other tomcat and the wicket session has a
>>>>>> reference to the old version of the serializable.
>>>>>>
>>>>>> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
>>>>>>
>>>>>>> yes
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
>>>>>>> <do...@douglasferguson.us> wrote:
>>>>>>>> Has anybody had success with wicket using tomcat's session
>>>>>>>> replication?
>>>>>>>>
>>>>>>>> D/
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>> ------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Igor Vaynberg <ig...@gmail.com>.
not with java serialization afaik
-igor
On Sat, Mar 6, 2010 at 6:52 AM, Douglas Ferguson
<do...@douglasferguson.us> wrote:
> I can't deal with removing fields or changing method signatures/implementations?
>
> D/
>
> On Mar 6, 2010, at 12:58 AM, Igor Vaynberg wrote:
>
>> as long as all you do is add fields you are ok...
>>
>> -igor
>>
>> On Fri, Mar 5, 2010 at 8:16 PM, Douglas Ferguson
>> <do...@douglasferguson.us> wrote:
>>> So as long as the serial I'd is the same the classlader won't care the
>>> fields don't match?
>>>
>>> Douglas Ferguson
>>> 512-293-7279
>>> Sent from my iPhone
>>>
>>> On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <ig...@gmail.com>
>>> wrote:
>>>
>>>> in the wicket code we override serial ids to 1, you should do the same
>>>> in your code.
>>>>
>>>> -igor
>>>>
>>>> On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
>>>> <do...@douglasferguson.us> wrote:
>>>>> I'm considering a 0 downtime deployment but am concerned with the
>>>>> amount of state in the wicket session.
>>>>>
>>>>> This is the scenario that concerns me.
>>>>>
>>>>> 1) There are 2 tomcats running
>>>>> 2) A change is made to a serializable object and the serial version
>>>>> id is updated
>>>>> 3) 1 tomcat instance is taken down for updating
>>>>> 4) tomcat instance comes back up with new object and now tries to
>>>>> update state from other tomcat and the wicket session has a
>>>>> reference to the old version of the serializable.
>>>>>
>>>>> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
>>>>>
>>>>>> yes
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
>>>>>> <do...@douglasferguson.us> wrote:
>>>>>>> Has anybody had success with wicket using tomcat's session
>>>>>>> replication?
>>>>>>>
>>>>>>> D/
>>>>>>>
>>>>>>> ---
>>>>>>> ------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---
>>>>>> ------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Douglas Ferguson <do...@douglasferguson.us>.
I can't deal with removing fields or changing method signatures/implementations?
D/
On Mar 6, 2010, at 12:58 AM, Igor Vaynberg wrote:
> as long as all you do is add fields you are ok...
>
> -igor
>
> On Fri, Mar 5, 2010 at 8:16 PM, Douglas Ferguson
> <do...@douglasferguson.us> wrote:
>> So as long as the serial I'd is the same the classlader won't care the
>> fields don't match?
>>
>> Douglas Ferguson
>> 512-293-7279
>> Sent from my iPhone
>>
>> On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <ig...@gmail.com>
>> wrote:
>>
>>> in the wicket code we override serial ids to 1, you should do the same
>>> in your code.
>>>
>>> -igor
>>>
>>> On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
>>> <do...@douglasferguson.us> wrote:
>>>> I'm considering a 0 downtime deployment but am concerned with the
>>>> amount of state in the wicket session.
>>>>
>>>> This is the scenario that concerns me.
>>>>
>>>> 1) There are 2 tomcats running
>>>> 2) A change is made to a serializable object and the serial version
>>>> id is updated
>>>> 3) 1 tomcat instance is taken down for updating
>>>> 4) tomcat instance comes back up with new object and now tries to
>>>> update state from other tomcat and the wicket session has a
>>>> reference to the old version of the serializable.
>>>>
>>>> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
>>>>
>>>>> yes
>>>>>
>>>>> -igor
>>>>>
>>>>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
>>>>> <do...@douglasferguson.us> wrote:
>>>>>> Has anybody had success with wicket using tomcat's session
>>>>>> replication?
>>>>>>
>>>>>> D/
>>>>>>
>>>>>> ---
>>>>>> ------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Igor Vaynberg <ig...@gmail.com>.
as long as all you do is add fields you are ok...
-igor
On Fri, Mar 5, 2010 at 8:16 PM, Douglas Ferguson
<do...@douglasferguson.us> wrote:
> So as long as the serial I'd is the same the classlader won't care the
> fields don't match?
>
> Douglas Ferguson
> 512-293-7279
> Sent from my iPhone
>
> On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <ig...@gmail.com>
> wrote:
>
>> in the wicket code we override serial ids to 1, you should do the same
>> in your code.
>>
>> -igor
>>
>> On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
>> <do...@douglasferguson.us> wrote:
>>> I'm considering a 0 downtime deployment but am concerned with the
>>> amount of state in the wicket session.
>>>
>>> This is the scenario that concerns me.
>>>
>>> 1) There are 2 tomcats running
>>> 2) A change is made to a serializable object and the serial version
>>> id is updated
>>> 3) 1 tomcat instance is taken down for updating
>>> 4) tomcat instance comes back up with new object and now tries to
>>> update state from other tomcat and the wicket session has a
>>> reference to the old version of the serializable.
>>>
>>> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
>>>
>>>> yes
>>>>
>>>> -igor
>>>>
>>>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
>>>> <do...@douglasferguson.us> wrote:
>>>>> Has anybody had success with wicket using tomcat's session
>>>>> replication?
>>>>>
>>>>> D/
>>>>>
>>>>> ---
>>>>> ------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Martin Grotzke <ma...@javakaffee.de>.
During deserialization, memcached-session-manager's xml/javolution based
serialization strategy just ignores fields that are no longer existing
in new classes. Of course one needs to be careful with renaming fields,
but I'd also like to have some mechanism to provide specific upgrade
handlers.
Cheers,
Martin
On Fri, 2010-03-05 at 20:16 -0800, Douglas Ferguson wrote:
> So as long as the serial I'd is the same the classlader won't care the
> fields don't match?
>
> Douglas Ferguson
> 512-293-7279
> Sent from my iPhone
>
> On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <ig...@gmail.com>
> wrote:
>
> > in the wicket code we override serial ids to 1, you should do the same
> > in your code.
> >
> > -igor
> >
> > On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
> > <do...@douglasferguson.us> wrote:
> >> I'm considering a 0 downtime deployment but am concerned with the
> >> amount of state in the wicket session.
> >>
> >> This is the scenario that concerns me.
> >>
> >> 1) There are 2 tomcats running
> >> 2) A change is made to a serializable object and the serial version
> >> id is updated
> >> 3) 1 tomcat instance is taken down for updating
> >> 4) tomcat instance comes back up with new object and now tries to
> >> update state from other tomcat and the wicket session has a
> >> reference to the old version of the serializable.
> >>
> >> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
> >>
> >>> yes
> >>>
> >>> -igor
> >>>
> >>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
> >>> <do...@douglasferguson.us> wrote:
> >>>> Has anybody had success with wicket using tomcat's session
> >>>> replication?
> >>>>
> >>>> D/
> >>>>
> >>>> ---
> >>>> ------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>>
> >>>
> >>> ---
> >>> ------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grotzke
http://www.javakaffee.de/blog/
Re: tomcat session replication
Posted by Douglas Ferguson <do...@douglasferguson.us>.
So as long as the serial I'd is the same the classlader won't care the
fields don't match?
Douglas Ferguson
512-293-7279
Sent from my iPhone
On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg" <ig...@gmail.com>
wrote:
> in the wicket code we override serial ids to 1, you should do the same
> in your code.
>
> -igor
>
> On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
> <do...@douglasferguson.us> wrote:
>> I'm considering a 0 downtime deployment but am concerned with the
>> amount of state in the wicket session.
>>
>> This is the scenario that concerns me.
>>
>> 1) There are 2 tomcats running
>> 2) A change is made to a serializable object and the serial version
>> id is updated
>> 3) 1 tomcat instance is taken down for updating
>> 4) tomcat instance comes back up with new object and now tries to
>> update state from other tomcat and the wicket session has a
>> reference to the old version of the serializable.
>>
>> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
>>
>>> yes
>>>
>>> -igor
>>>
>>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
>>> <do...@douglasferguson.us> wrote:
>>>> Has anybody had success with wicket using tomcat's session
>>>> replication?
>>>>
>>>> D/
>>>>
>>>> ---
>>>> ------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Igor Vaynberg <ig...@gmail.com>.
in the wicket code we override serial ids to 1, you should do the same
in your code.
-igor
On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
<do...@douglasferguson.us> wrote:
> I'm considering a 0 downtime deployment but am concerned with the amount of state in the wicket session.
>
> This is the scenario that concerns me.
>
> 1) There are 2 tomcats running
> 2) A change is made to a serializable object and the serial version id is updated
> 3) 1 tomcat instance is taken down for updating
> 4) tomcat instance comes back up with new object and now tries to update state from other tomcat and the wicket session has a reference to the old version of the serializable.
>
> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
>
>> yes
>>
>> -igor
>>
>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
>> <do...@douglasferguson.us> wrote:
>>> Has anybody had success with wicket using tomcat's session replication?
>>>
>>> D/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Martin Grotzke <ma...@javakaffee.de>.
Hi Douglas,
you might have a look at memcached-session-manager [1] which is a tomcat
session manager that stores sessions additionally in memcached (sessions
are still kept in and read from local memory for best performance).
The session serialization is pluggable and there's an xml based
serialization strategy (using javolution) to support code upgrade - of
course you still have to keep track of code changes so that "old"
session data structures can be deserialized to new data structures (have
a look at [2] for serialization strategies).
Btw, what I wonder: tomcat's session replication requires a
session.setAttribute to detect a session modification and trigger a
replication - is this requirement met by wicket? And apart from wicket,
to me this seems to be a rather hard requirement for web applications.
Who can guarantee, that nobody is getting a session attribute and
modifying it without invoking session.setAttribute afterwards...?
Right now I'm implementing a feature so that sessions are only sent to
memcached if the session data changed. This is completely transparent,
so that you might retrieve a complex session attribute, change some
property of it and this change will be detected so that the session will
be updated in memcached (more details on this can be found at [3]).
Cheers,
Martin
[1] http://code.google.com/p/memcached-session-manager/
[2] http://code.google.com/p/memcached-session-manager/wiki/SerializationStrategies
[3] http://code.google.com/p/memcached-session-manager/issues/detail?id=36
On Fri, 2010-03-05 at 12:15 -0800, Douglas Ferguson wrote:
> I'm considering a 0 downtime deployment but am concerned with the amount of state in the wicket session.
>
> This is the scenario that concerns me.
>
> 1) There are 2 tomcats running
> 2) A change is made to a serializable object and the serial version id is updated
> 3) 1 tomcat instance is taken down for updating
> 4) tomcat instance comes back up with new object and now tries to update state from other tomcat and the wicket session has a reference to the old version of the serializable.
>
> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
>
> > yes
> >
> > -igor
> >
> > On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
> > <do...@douglasferguson.us> wrote:
> >> Has anybody had success with wicket using tomcat's session replication?
> >>
> >> D/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Martin Grotzke
http://www.javakaffee.de/blog/
Re: tomcat session replication
Posted by Douglas Ferguson <do...@douglasferguson.us>.
I'm considering a 0 downtime deployment but am concerned with the amount of state in the wicket session.
This is the scenario that concerns me.
1) There are 2 tomcats running
2) A change is made to a serializable object and the serial version id is updated
3) 1 tomcat instance is taken down for updating
4) tomcat instance comes back up with new object and now tries to update state from other tomcat and the wicket session has a reference to the old version of the serializable.
On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
> yes
>
> -igor
>
> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
> <do...@douglasferguson.us> wrote:
>> Has anybody had success with wicket using tomcat's session replication?
>>
>> D/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: tomcat session replication
Posted by Igor Vaynberg <ig...@gmail.com>.
yes
-igor
On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
<do...@douglasferguson.us> wrote:
> Has anybody had success with wicket using tomcat's session replication?
>
> D/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org