no, but you are welcome to test and ping us back with the results :) -igor
On Mon, Dec 13, 2010 at 8:14 PM, Michal Kurtak <michal.kur...@gmail.com> wrote: > And one more thing. do you have some benchmarks comparing > DiskDataStore, AsynchronousDataStore to Pagemaps stored in http > sessions (as in earlier wicket versions)? I mean writing pages to > disks comparing to writing them to http session (and replicating big > sessions)? > > 2010/12/13 Michal Kurtak <michal.kur...@gmail.com>: >> Hmm... This solutions seems really good. sorry for bothering >> >> michal >> >> >> 2010/12/13 Igor Vaynberg <igor.vaynb...@gmail.com>: >>> 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 >>> >>> >> > > --------------------------------------------------------------------- > 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
