Yeah, that would be cool, if you havent already found it, the latest version
of the code is attached to the JIRA issue.

Presumably if this wasnt to go into wicket core, we would have no problem
making the wicket tim have a dependancy on wicket?

Richard


Stefan Fußenegger wrote:
> 
> 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.
>>>
>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Terracotta-integration-tp18168616p18360395.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Reply via email to