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 <[email protected]> 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 >> <[email protected]> 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 >>>> <[email protected]> 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 >>>>>> <[email protected]> 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" <[email protected]> >>>>>>> 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 >>>>>>>> <[email protected]> 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 >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> Has anybody had success with wicket using tomcat's session >>>>>>>>>>> replication? >>>>>>>>>>> >>>>>>>>>>> D/ >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> ------------------------------------------------------------------ >>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
