Don't think there is a better source for feedback available ;)
Ari Zilka wrote: > > Wow. Not acceptable...sorry about that. > > Anyways, Wicket core developers are on this list, no? What is the > next step toward blessing TerracottaPageStore? I suggest that before > we bother Wicket, we pass it by Terracotta folks to make sure it is > going to be the best foot fwd for both technologies. I was listening > on this thread, but haven't yet looked to see if the collections and > locking structures will perform well and/or could be optimized for > us. Shall I do that quick scan now? > > --Ari > > On Jul 9, 2008, at 4:33 AM, Stefan Fußenegger wrote: > >> >> Hi Ari, >> >> It probably depends on whether TerracottaPageStore makes it into >> Wicket or >> not. So we need some core developers to comment on that. >> >> If TerracottaPageStore finds its way into TC, I'd sign that >> contributor >> agreement (btw: I already wanted to contribute my hibernate-search, >> but >> haven't heard anything from the TC folks for weeks now.) >> >> Regards >> Stefan >> >> >> >> Ari Zilka wrote: >>> >>> To get this into the terracotta forge we just need the author to >>> sign a >>> contributor agreement. Then we will review the code, check it in, >>> and all >>> is good. >>> >>> You can also get write access to the terracotta forge svn if you >>> plan to >>> maintain the module. >>> >>> Kewl kewl. I am excited to get the contribution. Let me know how >>> you guys >>> wish to proceed! >>> >>> --Ari >>> >>> -- >>> Sent from my handheld >>> >>> [Message delivered by NotifyLink] >>> >>> ----------Original Message---------- >>> >>> From: richardwilko <[EMAIL PROTECTED]> >>> Sent: Tue, July 08, 2008 3:38 AM >>> To: [email protected] >>> Subject: Re: Terracotta integration >>> >>> >>> >>> Ok, cool, >>> >>> Initial testing shows that no extra synchronisation is required. >>> It works >>> :) >>> >>> However I had to modify the getHttpSession method, the test to make >>> sure >>> the >>> sessionid is the same, that doesn't work clustered as the session id >>> contains jvm route (ie machine identifier) so changes from machine to >>> machine. The first part of the id is the same (the part before the >>> dot) >>> so >>> we could either implement some text splitting or remove it >>> completely. >>> >>> I also forgot about the other stuff that gets stored in >>> httpsession, ie >>> the >>> actual session object, so my simple 4 class config didnt work. I >>> just >>> copied the original wicket one into mine, there are some extra >>> classes >>> that >>> are now distributed that dont need to be, but this was the quickest >>> way to >>> get it working. IClusterable is used everywhere so will be pain if >>> we >>> want >>> to sort that out. >>> >>> After more testing i will post back a merged version of code, but >>> all is >>> looking good, >>> >>> cheers, >>> >>> Richard >>> >>> >>> >>> Stefan Fußenegger wrote: >>>> >>>> As I said, it's a matter of taste and not worth a discussion. I >>>> think I >>>> can handle it, if you want to stick with your solution ;) >>>> >>>> With "complain" I meant: "All changes to clustered objects must >>>> happen >>>> within the context of a Terracotta transaction. This means that a >>>> thread >>>> must acquire a clustered lock prior to modifying the state of any >>>> clustered objects. If a thread attempts to modify a clustered object >>>> outside the context of a terracotta transaction, a runtime >>>> exception will >>>> be thrown." ( >>>> http://www.terracotta.org/confluence/display/docs1/Concept+and+Architecture+Guide#ConceptandArchitectureGuide-Transactions >>>> Terracotta Product Documentation ). PageMapStore is clustered >>>> after being >>>> stored in the session. Therefore, modifications to >>>> PageMapStore._pageMaps >>>> (as in getPageMap(String)) will cause an exception outside of a >>>> transaction. I can't see where the transaction starts, but testing >>>> this >>>> in >>>> a clustered environment will quickly give an answer whether we need >>>> further synchronization or not (maybe you already did this, while >>>> I only >>>> tested without actually using TC clustering). I added the further >>>> synchronization if needed >>>> >>>> btw: getPageStore(...) should probably be renamed as it in fact >>>> returns a >>>> PageMapStore, not a PageStore, same for getPageMap(...) that >>>> returns a >>>> PageStore. >>>> >>>> i think a nice side effect of this new implementation is that wicket >>>> components need not be IClusterable anymore. we always test our >>>> app in >>>> "pure wicket mode" and test it clustered prior to deployment. we >>>> always >>>> find some objects that are Serializable but not IClusterable, hence >>>> causing exceptions with TC. Using serialization of pages, both modes >>>> would >>>> need Serializable objects only. >>>> >>>> regards >>>> stefan >>>> >>>> http://www.nabble.com/file/p18335661/OurTerracottaPageStore.java >>>> OurTerracottaPageStore.java >>>> >>>> >>>> >>>> >>>> richardwilko wrote: >>>>> >>>>> Looks good, >>>>> >>>>> >>>>> Stefan Fußenegger wrote: >>>>>> >>>>>> - I wouldn't use an extra class just to wrap a HashMap of >>>>>> PageStore. I >>>>>> would just put them into the plain session. But finally, this is >>>>>> just a >>>>>> matter of taste. I even think that this class lacks proper >>>>>> synchronization. Doesn't Terracotta complain about modifying an >>>>>> instance >>>>>> outside of a transaction?? >>>>>> >>>>> >>>>> I disagree, I think it makes the code cleaner as all the stuff to >>>>> do >>>>> with >>>>> creating PageStores (and debug information) is encapsulated in the >>>>> class. >>>>> I don't think that the synchronisation is an issue, im not sure >>>>> what you >>>>> mean about terracotta complaining, if Ari is still watching this >>>>> thread >>>>> then he can probably answer the question. >>>>> >>>>> It is a pain that you cant get the last element of the list, but >>>>> your >>>>> solution works well, I tweaked it slightly to remove a not needed >>>>> if >>>>> statement (you dont need to check the page id, the subset stuff >>>>> takes >>>>> care of it). >>>>> >>>>> I'm gonna put this slightly modified class through our test >>>>> environment >>>>> here where i work and throw loads of simulated users at it to see >>>>> how it >>>>> works. >>>>> >>>>> I have removed the wicket module from my terracotta config as this >>>>> currently forces the use of httpsessionstore. Also with our >>>>> solution we >>>>> only need to instrument 4 classes so i'm not using the IClusterable >>>>> thing >>>>> in the config, i'm just declaring the classes manually. >>>>> I would be good to find out how we go about modifying the wicket >>>>> tim >>>>> (probably another question for Ari there). I downloaded the >>>>> terracotta >>>>> source but couldn't get it to build. >>>>> >>>>> Richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Terracotta-integration-tp18168616p18336333.html >>> Sent from the Wicket - Dev mailing list archive at Nabble.com. >>> >>> >> >> >> ----- >> ------- >> Stefan Fußenegger >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;) >> -- >> View this message in context: >> http://www.nabble.com/Terracotta-integration-tp18168616p18359420.html >> Sent from the Wicket - Dev mailing list archive at Nabble.com. >> > > > ----- ------- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- View this message in context: http://www.nabble.com/Terracotta-integration-tp18168616p18359962.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
