when the page that is stored in http session is deserialized on another node it is also spooled to disk. so in a cluster all nodes have identical spooled pages - so everything should work.
-igor On Mon, Dec 13, 2010 at 8:00 PM, Michal Kurtak <michal.kur...@gmail.com> wrote: > Thank you for your replies Igor. > > I have another question regarding to clustered environment. Suppose we > have versioned pages opened in two windows. If one node goes down, > only the last page user made request from is stored in http session > and replicated to other nodes. So i suppose that only one page would > work and the state from the second page is lost. > > So multi-window support for stateful pages (even versioned) wouldn't > work in clustered environment. Is this true? > > I think that even weird javascript solution for multiple windows would > be good (it could be turned off by default), because we are unable to > migrate our existing wicket projects, or create stateful application > in multiple windows/tabs running in the cluster. This was supported > out-of-box by wicket previous versions. I know that there is a > possibility to provide implementation IPageManager, but there is > missing support for browser window detection so its a bit more > complicated to implement IPageManager supporting multiple windows in > clustered environment. > > BR, > Michal > > > 2010/12/13 Igor Vaynberg <igor.vaynb...@gmail.com>: >> On Sat, Dec 11, 2010 at 12:04 PM, Michal Kurtak <michal.kur...@gmail.com> >> wrote: >>> Hi folks, >>> >>> I know that there has been a lot of written about pagestores and >>> multi-window support in wicket 1.5, but i have several other >>> questions: >>> >>> 1. Is multi-window supported for non-versioned pages? >>> >>> If page is versioned everything works ok, but i always get >>> StalePageExceptions when i use multiple windows/tabs with >>> non-versioned pages. >>> I think that StalePageException is useful in some cases when you wanna >>> be sure that user has same page in all windows, but in older versions >>> of wicket it was possible to have non versioned pages and multi-window >>> support together (e.g. we have an application written in wicket 1.2.6 >>> that uses non-versioned pages in multiple windows) >> >> no, it is not supported. supporting it has been problematic even in >> 1.4.x series where it required javascript and introduced a strange >> redirect that happened as soon as the page was loaded. unversioned >> pages also cause weird issues with the back button. if you want >> something that is unversioned then i think building it as stateless >> makes more sense. >> >>> 2. How page stores work in clustered environment? >>> >>> In older versions of wicket we used pagemaps stored in HttpSession. >>> When one node in cluster refuses to handle request, it was >>> successfully handled by another nod, because HttpSession was >>> replicated to another node. We have used non-versioned pages (no back >>> button support needed) and in one pagemap there was max 5 pages. >>> Wicket provided this functionality out-of-box. >> >> in both 1.4.x and 1.5.x by default we store the current page in >> session and the rest are spooled to disk. the current page is >> replicated to all nodes since it is stored in session, so any node can >> pick up a request. >> >>> >>> 3. How to achieve this in wicket 1.5? >>> >>> I have found PersistentPageManager which uses IPageStore to store >>> pages. Pages are stored on disk by default, but there is also thread >>> safe SerializedPagesCache with SoftReferences. Theres no out-of-box >>> solution to store pages in HttpSession. >>> >>> I have also found file page-management.txt in org.apache.wicket.page >>> package. It contains proposal of other pagamanagers and multi-window >>> support for non-versioned pages. >>> >>> The proposal contains classes >>> >>> PersistentPageManager with DiskPageStore and >>> SecondLevelCacheSessionStore for versioned pages >>> SessionManager for holding non versioned pages in HttpSession. >>> >>> 4. Can we expect that this proposal will be implemented in wicket 1.5 >>> final version? >> >> no. the current version is feature complete and we are concentrating >> on bugfixing. a more sophisticated page management may be introduced >> in the future. we have concentrated on the 99% usecase and simplified >> the code for that. you can implement your own page storage strategies >> as you see fit. >> >> -igor >> >>> >>> Thanks for your replies. >>> >>> BR, >>> Michal Kurtak >>> >>> --------------------------------------------------------------------- >>> 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 >> >> > > --------------------------------------------------------------------- > 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
