We are developing (at my employer) UI library based on wicket 1.5 (former version was based on wicket 1.2.6.) and we will make performance measurements so I can provide you some results:) But the tests will be made in January, if it doesn't matter
2010/12/13 Igor Vaynberg <igor.vaynb...@gmail.com>: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
