Terracotta integration

[richardwilko]

I'm not sure if pages are always inserted in version number, for example, if you go back to a previous page and start doing something on it again, it will start inserting pages with a lower version number (i think anyway)

I also have a modified version, it seems a bit simpler than yours and it will work not matter when pages are inserted or deleted.  It uses an additional TreeSet on the PageKeys; using the TreeSet's ordering it is easy to quickly find specific versions, or the highest ajax version for a normal version, or to find if a version exists.

I also added some debug code, and made the number of pages limit optional.

See what you think

OurTerracottaPageStore.java

Richard




Ok, i now used a LinkedHashMap and a limit of 1000 pages per PageMap. This should give sufficient protection and rarely happen.

You were right with the -1 ajaxVersionNumber. I fixed that.

I also fixed the reference to the highestAjaxVersion as there needs to be such a reference for each version, not only each pageId. There is now an additional HashMap. So finally this implemenation requires two HashMaps and a LinkedHashMap per PageMap.

For this implementation, I assumed that pages are inserted in order (according to their versions). Could somebody confirm that? Otherwise, the map pointing to the highest ajaxVersion would need to be updated when the currently highest ajaxVersion is deleted due to an exceeded max pages limit (one would have to search for a lower ajaxVersion and point to that page). Otherwise, I'd say we are quite close to the DiskPageStore implementation (not being asynchronous and not implementing ISerializationAwarePageStore - which is only used for Wicket's session clustering, right?)

regards

MyTerracottaPageStore.java


Im still not sure about not limiting the number of pages to keep in session, even DiskPageStore has some sort of limit, imo not having a limit exposes us to the possibility of a single malicious user grinding the system to a halt.  Yes terracotta will persist it to disk if needs be, but if that session is is current active use then it will be paging to and from disk all the time.

I would like to get the opinion of some other people about this.

Also I don't see how the the -1 ajax version can work; in disk based store it treats the -1 the same as in getPage, where it just looks for the highest version, in our case it will construct a key with the -1 value in it, i.e. it will only find the page where ajax version number is -1.  Since this cant happen, contains page wont work.  We could probably use the helper structure thing to simplify this though.

Richard

Stefan Fußenegger wrote:

1+2) well, it will only add pages as long as the session is alive. if a page isn't used frequently it will be moved to and later persisted by the TC server and finally GCed together with its session. therefore i don't think deleting old pages is necessary. or do you have a special use case where this could be problematic? maybe a bot crawling thousands of pages could generate tons of serialized page? but is this really a problem?

3) okay, didn't see that little piece of javadoc. I think an extra structure keeping track of most recent versions of pageIds could help to make these searches efficient.

I changed my code:
- one store per PageMapName, making deletes more efficient
- version info stored for all pageIds (HashMap<Integer,VersionInfo>) where VersionInfo has a pointer to the most recent page and highest ajaxVersionNumber

Comments?

New file: (untested!) MyTerracottaPageStore.java

richardwilko wrote:

Hi Stefan,

Looking through your code I see a couple of issues:

1) There is no limit on the number of pages stored in the pagemap, pages could get added forever.  I feel there needs to be a way to limit the number of pages stored, with oldest ones discarded first.  This is how DiskPageStore works.

2) Following on from point 1, a HashMap does not keep insertion order so it is not possible to remove the oldest ones easily.  A simple change to LinkedHashMap would solve this and make point 1 easy to implement.  However storing all the pagemaps together does mean that the most recent pages from one pagemap could get removed due to high use of another pagemap.  In this case when the user goes back to the other pagemap he/she will encounter an exception.

3) Your getPage code is not general enough; from the javadocs for getPage in IPageStore:
* If ajaxVersionNumber is -1 and versionNumber is specified, the page store must return the page with highest ajax version.
* If both versionNumber and ajaxVersioNumber are -1, the pagestore must return last touched (saved) page version with given id.
Your method of constructing a key object wouldn't work in these situations, as it would only find exact matches, and so getPage would require iterating through the entire HashMap and looking at every entry.

This issue is the reason why I went for the nested structure I used.  I do agree that a single storage map would ideally be better, especially as this make it easier to better manage the number of pages stored, but i'm not sure if it is the most efficient method of storage for the complex getPage requirements.  By efficient i mean execution time rather than memory usage.

Thoughts?

Richard

Stefan Fußenegger wrote:

Hi Richard,

I had a thorough look on your code. I have the following remarks:

- yes, SerializedPage must be clustered and should therefore implement IClusterable (it is already Serializable, it should therefore be okay to change)
- I found two problems with your implementation:
  1) unbind() is called during invalidation of a session. getPageStore() will therefore result in a NPE as there is no WebRequest
  2) according to the JavaDoc of DiskPageStore#removePage(SessionEntry, String, int) ("page id to remove or -1 if the whole pagemap should be removed") calling removePage(String, String, int) with an id of -1 should delete all pages of a pageMap (however, that's not documented in the JavaDoc of IPageStore!)
- I feel that all pages could be in a single HashMap (rather than using 3 levels of nested HashMaps and HashSets). I therefore implemented my own PageStore based on your ideas to confirm my feelings (using a single HashMap per sesison, using less Hash(Map|Set) iterations; access synchronized using a ReentrantReadWriteLock which I think has quite good performance with TC). Please have a look. We can probablyMyTerracottaPageStore.java merge our ideas for best results!

Regards
Stefan


MyTerracottaPageStore.java

[Stefan Fußenegger]

First of all, I like the new name ;)

- Using a TreeSet with subsets is a great idea!

- 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??

- The way getPage(...) with versionNumber -1 is implemented isn't really nice. Too bad that LinkedHashMap doesn't maintain a pointer to the end of the list although it is a double linked one :-( would make that task much faster. Another possibility would be to make a TreeMap<PageKey,Integer> out of the current TreeSet (which is backed by a TreeMap anyway). The integer would be a counter that indicates the insertion order. One would therefore only have to iterate over a subMap() of the pages containing all PageKeys with the pageId in question (implemented but not tested yet - not gonna happen today).

OurTerracottaPageStore.java

I think we are quite close to something really cool ;)



I'm not sure if pages are always inserted in version number, for example, if you go back to a previous page and start doing something on it again, it will start inserting pages with a lower version number (i think anyway)

I also have a modified version, it seems a bit simpler than yours and it will work not matter when pages are inserted or deleted.  It uses an additional TreeSet on the PageKeys; using the TreeSet's ordering it is easy to quickly find specific versions, or the highest ajax version for a normal version, or to find if a version exists.

I also added some debug code, and made the number of pages limit optional.

See what you think

OurTerracottaPageStore.java

Richard




Ok, i now used a LinkedHashMap and a limit of 1000 pages per PageMap. This should give sufficient protection and rarely happen.

You were right with the -1 ajaxVersionNumber. I fixed that.

I also fixed the reference to the highestAjaxVersion as there needs to be such a reference for each version, not only each pageId. There is now an additional HashMap. So finally this implemenation requires two HashMaps and a LinkedHashMap per PageMap.

For this implementation, I assumed that pages are inserted in order (according to their versions). Could somebody confirm that? Otherwise, the map pointing to the highest ajaxVersion would need to be updated when the currently highest ajaxVersion is deleted due to an exceeded max pages limit (one would have to search for a lower ajaxVersion and point to that page). Otherwise, I'd say we are quite close to the DiskPageStore implementation (not being asynchronous and not implementing ISerializationAwarePageStore - which is only used for Wicket's session clustering, right?)

regards

MyTerracottaPageStore.java


Im still not sure about not limiting the number of pages to keep in session, even DiskPageStore has some sort of limit, imo not having a limit exposes us to the possibility of a single malicious user grinding the system to a halt.  Yes terracotta will persist it to disk if needs be, but if that session is is current active use then it will be paging to and from disk all the time.

I would like to get the opinion of some other people about this.

Also I don't see how the the -1 ajax version can work; in disk based store it treats the -1 the same as in getPage, where it just looks for the highest version, in our case it will construct a key with the -1 value in it, i.e. it will only find the page where ajax version number is -1.  Since this cant happen, contains page wont work.  We could probably use the helper structure thing to simplify this though.

Richard

Stefan Fußenegger wrote:

1+2) well, it will only add pages as long as the session is alive. if a page isn't used frequently it will be moved to and later persisted by the TC server and finally GCed together with its session. therefore i don't think deleting old pages is necessary. or do you have a special use case where this could be problematic? maybe a bot crawling thousands of pages could generate tons of serialized page? but is this really a problem?

3) okay, didn't see that little piece of javadoc. I think an extra structure keeping track of most recent versions of pageIds could help to make these searches efficient.

I changed my code:
- one store per PageMapName, making deletes more efficient
- version info stored for all pageIds (HashMap<Integer,VersionInfo>) where VersionInfo has a pointer to the most recent page and highest ajaxVersionNumber

Comments?

New file: (untested!) MyTerracottaPageStore.java

richardwilko wrote:

Hi Stefan,

Looking through your code I see a couple of issues:

1) There is no limit on the number of pages stored in the pagemap, pages could get added forever.  I feel there needs to be a way to limit the number of pages stored, with oldest ones discarded first.  This is how DiskPageStore works.

2) Following on from point 1, a HashMap does not keep insertion order so it is not possible to remove the oldest ones easily.  A simple change to LinkedHashMap would solve this and make point 1 easy to implement.  However storing all the pagemaps together does mean that the most recent pages from one pagemap could get removed due to high use of another pagemap.  In this case when the user goes back to the other pagemap he/she will encounter an exception.

3) Your getPage code is not general enough; from the javadocs for getPage in IPageStore:
* If ajaxVersionNumber is -1 and versionNumber is specified, the page store must return the page with highest ajax version.
* If both versionNumber and ajaxVersioNumber are -1, the pagestore must return last touched (saved) page version with given id.
Your method of constructing a key object wouldn't work in these situations, as it would only find exact matches, and so getPage would require iterating through the entire HashMap and looking at every entry.

This issue is the reason why I went for the nested structure I used.  I do agree that a single storage map would ideally be better, especially as this make it easier to better manage the number of pages stored, but i'm not sure if it is the most efficient method of storage for the complex getPage requirements.  By efficient i mean execution time rather than memory usage.

Thoughts?

Richard

Stefan Fußenegger wrote:

Hi Richard,

I had a thorough look on your code. I have the following remarks:

- yes, SerializedPage must be clustered and should therefore implement IClusterable (it is already Serializable, it should therefore be okay to change)
- I found two problems with your implementation:
  1) unbind() is called during invalidation of a session. getPageStore() will therefore result in a NPE as there is no WebRequest
  2) according to the JavaDoc of DiskPageStore#removePage(SessionEntry, String, int) ("page id to remove or -1 if the whole pagemap should be removed") calling removePage(String, String, int) with an id of -1 should delete all pages of a pageMap (however, that's not documented in the JavaDoc of IPageStore!)
- I feel that all pages could be in a single HashMap (rather than using 3 levels of nested HashMaps and HashSets). I therefore implemented my own PageStore based on your ideas to confirm my feelings (using a single HashMap per sesison, using less Hash(Map|Set) iterations; access synchronized using a ReentrantReadWriteLock which I think has quite good performance with TC). Please have a look. We can probablyMyTerracottaPageStore.java merge our ideas for best results!

Regards
Stefan


MyTerracottaPageStore.java

[richardwilko]

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

[Stefan Fußenegger]

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." (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

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

[richardwilko]

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



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." (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

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

[Stefan Fußenegger]

I believe you can remove the sessionId check. It was just meant to prove my expectation that a passed sessionId is always equal to the current session's id (which I think it did).

The extra synchronization still makes sense as it avoids that two concurrent threads add a PageStore for the same pageMapName. This could cause strange (and hard to reproduce/debug) errors.

good luck with your testing!




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." (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

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

[richardwilko]

I have created a JIRA issue for this now we have a working candidate.

https://issues.apache.org/jira/browse/WICKET-1738

I have left your new synchronization in there, and removed thed session check



I believe you can remove the sessionId check. It was just meant to prove my expectation that a passed sessionId is always equal to the current session's id (which I think it did).

The extra synchronization still makes sense as it avoids that two concurrent threads add a PageStore for the same pageMapName. This could cause strange (and hard to reproduce/debug) errors.

good luck with your testing!




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." (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

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

[Ari Zilka]

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 <richardjohnwilkinson@...>
Sent: Tue, July 08, 2008 3:38 AM
To: dev@...
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]

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 <[e-mail]>
Sent: Tue, July 08, 2008 3:38 AM
To: [e-mail]
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.

[Ari Zilka]

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 <richardjohnwilkinson@...>
>> Sent: Tue, July 08, 2008 3:38 AM
>> To: dev@...
>> 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]

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 <[e-mail]>
>> Sent: Tue, July 08, 2008 3:38 AM
>> To: [e-mail]
>> 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.
>

[richardwilko]

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


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 <[e-mail]>
>> Sent: Tue, July 08, 2008 3:38 AM
>> To: [e-mail]
>> 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.
>

[igor.vaynberg]

i dont see a reason for this to go into wicket. it is a terracotta
specific optimization and there is already a terracotta-wicket module
right? luckily so far it has no dependencies on anything terracotta
specific, but once their guys seriously optimize it will that remain
true?

-igor

On Wed, Jul 9, 2008 at 5:41 AM, richardwilko
<richardjohnwilkinson@...> wrote:

>
> 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 <richardjohnwilkinson@...>
>>>>> Sent: Tue, July 08, 2008 3:38 AM
>>>>> To: dev@...
>>>>> 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.
>
>

[Eelco Hillenius]

On Wed, Jul 9, 2008 at 7:13 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
> i dont see a reason for this to go into wicket. it is a terracotta
> specific optimization and there is already a terracotta-wicket module
> right?

And that would be easier for users too I would think: one less
dependency to worry about.

Eelco

[richardwilko]

to use the new class you would put something like this in your application class:

        @Override
        public ISessionStore newSessionStore() {
                return new SecondLevelCacheSessionStore(this, new TerracottaPageStore(100));
        }

where the 100 is number of pages to keep as history, which is user defined (please feel free comment on if you think we need a limit or not, or what a sensible number is).  There is also a default constructor which doesn't impose a limit (it will store every page in the page map).  This configurable limit means that we cant really override this method with the asm stuff terracotta uses as is done currently.

This means to use terracotta the user will need to add the wicket tim jar file as a dependency to their project, so they can compile their code.

However the main reason I thought it might be useful to add it into the wicket source is because this page store may have other uses apart from terracotta, it would be useful in any instance where DiskPageStore is not suitable (disk access too slow or not allowed?  Probably not ever going to be an issue I know and i'm certainly not suggesting that it should replace DiskPageStore).   If we had called it HttpSessionPageStore, then it might have been clearer what the class actually is.  you could also pretty easily modify it to be able to optionally store non-serialized Page objects so that people who, for whatever reason, cannot serialize their pages would not have to use the old HttpSessionStore (which i believe has some other problems).

Having said that if you don't feel that it should go into wicket core, then it can quite happily live in the wicket tim and im not going to say any more on it :)

However it still would be useful if org.apache.wicket.protocol.http.pagestore.AbstractPageStore$SerializedPage could implement IClusterable rather than Serializable as this will make the terracotta config simpler.

Cheers,

Richard

[Ari Zilka]

1. Can I get the tc-config.xml that goes with this

2. Terracotta TIMs can do almost anything we need to do here.  We can  
replace a method on class load.  We can probably pain $SerializedPage  
inner class to implement the IClusterable interface as well.  I dunno  
about removing Serializable though.  Would we have to?

Anyways, if you ship me a list of what your ideal TIM would do I will  
get it configured, bundled in OSGi and back to you by Monday.

I agree though.  The TIM could live at Terracotta's forge but should  
live with Wicket as it needs to be maintained with changes in Wicket  
moreso than changes in Terracotta.

--Ari

On Jul 10, 2008, at 1:58 AM, richardwilko wrote:

>
> to use the new class you would put something like this in your  
> application
> class:
>
> @Override
> public ISessionStore newSessionStore() {
> return new SecondLevelCacheSessionStore(this, new
> TerracottaPageStore(100));
> }
>
> where the 100 is number of pages to keep as history, which is user  
> defined
> (please feel free comment on if you think we need a limit or not, or  
> what a
> sensible number is).  There is also a default constructor which  
> doesn't
> impose a limit (it will store every page in the page map).  This
> configurable limit means that we cant really override this method  
> with the
> asm stuff terracotta uses as is done currently.
>
> This means to use terracotta the user will need to add the wicket  
> tim jar
> file as a dependency to their project, so they can compile their code.
>
> However the main reason I thought it might be useful to add it into  
> the
> wicket source is because this page store may have other uses apart  
> from
> terracotta, it would be useful in any instance where DiskPageStore  
> is not
> suitable (disk access too slow or not allowed?  Probably not ever  
> going to
> be an issue I know and i'm certainly not suggesting that it should  
> replace
> DiskPageStore).   If we had called it HttpSessionPageStore, then it  
> might
> have been clearer what the class actually is.  you could also pretty  
> easily
> modify it to be able to optionally store non-serialized Page objects  
> so that
> people who, for whatever reason, cannot serialize their pages would  
> not have
> to use the old HttpSessionStore (which i believe has some other  
> problems).
>
> Having said that if you don't feel that it should go into wicket  
> core, then
> it can quite happily live in the wicket tim and im not going to say  
> any more
> on it :)
>
> However it still would be useful if
> org.apache.wicket.protocol.http.pagestore.AbstractPageStore
> $SerializedPage
> could implement IClusterable rather than Serializable as this will  
> make the
> terracotta config simpler.
>
> Cheers,
>
> Richard
> --
> View this message in context: http://www.nabble.com/Terracotta-integration-tp18168616p18378657.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>

[richardwilko]

tc-config is almost the same, except need to add

<include>
<class-expression>org.apache.wicket.protocol.http.pagestore.AbstractPageStore$SerializedPage</class-expression>
</include>

or need to make this page implement IClusterable with bytecode stuff,  but if you do use bytecode, this needs to happen before it starts looking for instrumented classes (IClusterable is an interface used in wicket to say that the class should be instrumented, is is an extension of the Serializable interface).

The wicket tim needs to remove the current code which forces the httpsessionstore, but apart from that i dont think it needs to do anything else.

Maybe other people will have ideas?

Ari Zilka wrote:

1. Can I get the tc-config.xml that goes with this

2. Terracotta TIMs can do almost anything we need to do here.  We can  
replace a method on class load.  We can probably pain $SerializedPage  
inner class to implement the IClusterable interface as well.  I dunno  
about removing Serializable though.  Would we have to?

Anyways, if you ship me a list of what your ideal TIM would do I will  
get it configured, bundled in OSGi and back to you by Monday.

I agree though.  The TIM could live at Terracotta's forge but should  
live with Wicket as it needs to be maintained with changes in Wicket  
moreso than changes in Terracotta.

--Ari

[Johan Compagner]

we can make SerializePage implement IClusterable  thats not a problem


On Thu, Jul 10, 2008 at 1:00 PM, richardwilko <
richardjohnwilkinson@...> wrote:

>
> tc-config is almost the same, except need to add
>
> <include>
>
> <class-expression>org.apache.wicket.protocol.http.pagestore.AbstractPageStore$SerializedPage</class-expression>
> </include>
>
> or need to make this page implement IClusterable with bytecode stuff,  but
> if you do use bytecode, this needs to happen before it starts looking for
> instrumented classes (IClusterable is an interface used in wicket to say
> that the class should be instrumented, is is an extension of the
> Serializable interface).
>
> The wicket tim needs to remove the current code which forces the
> httpsessionstore, but apart from that i dont think it needs to do anything
> else.
>
> Maybe other people will have ideas?
>
>
>
>
>
>
> Ari Zilka wrote:
> >
> > 1. Can I get the tc-config.xml that goes with this
> >
> > 2. Terracotta TIMs can do almost anything we need to do here.  We can
> > replace a method on class load.  We can probably pain $SerializedPage
> > inner class to implement the IClusterable interface as well.  I dunno
> > about removing Serializable though.  Would we have to?
> >
> > Anyways, if you ship me a list of what your ideal TIM would do I will
> > get it configured, bundled in OSGi and back to you by Monday.
> >
> > I agree though.  The TIM could live at Terracotta's forge but should
> > live with Wicket as it needs to be maintained with changes in Wicket
> > moreso than changes in Terracotta.
> >
> > --Ari
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Terracotta-integration-tp18168616p18380445.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>

[Johan Compagner]

In the current terracotta module will terracotta not monitor/instrument also
pages, components and models?

If we have this page store.. Then terracotta should only work on that page
store class right?
The rest is something that shouldnt be touched

johan


On Thu, Jul 10, 2008 at 12:40 PM, Ari Zilka <ari@...> wrote:

> 1. Can I get the tc-config.xml that goes with this
>
> 2. Terracotta TIMs can do almost anything we need to do here.  We can
> replace a method on class load.  We can probably pain $SerializedPage inner
> class to implement the IClusterable interface as well.  I dunno about
> removing Serializable though.  Would we have to?
>
> Anyways, if you ship me a list of what your ideal TIM would do I will get
> it configured, bundled in OSGi and back to you by Monday.
>
> I agree though.  The TIM could live at Terracotta's forge but should live
> with Wicket as it needs to be maintained with changes in Wicket moreso than
> changes in Terracotta.
>
> --Ari
>
>
> On Jul 10, 2008, at 1:58 AM, richardwilko wrote:
>
>
>> to use the new class you would put something like this in your application
>> class:
>>
>>        @Override
>>        public ISessionStore newSessionStore() {
>>                return new SecondLevelCacheSessionStore(this, new
>> TerracottaPageStore(100));
>>        }
>>
>> where the 100 is number of pages to keep as history, which is user defined
>> (please feel free comment on if you think we need a limit or not, or what
>> a
>> sensible number is).  There is also a default constructor which doesn't
>> impose a limit (it will store every page in the page map).  This
>> configurable limit means that we cant really override this method with the
>> asm stuff terracotta uses as is done currently.
>>
>> This means to use terracotta the user will need to add the wicket tim jar
>> file as a dependency to their project, so they can compile their code.
>>
>> However the main reason I thought it might be useful to add it into the
>> wicket source is because this page store may have other uses apart from
>> terracotta, it would be useful in any instance where DiskPageStore is not
>> suitable (disk access too slow or not allowed?  Probably not ever going to
>> be an issue I know and i'm certainly not suggesting that it should replace
>> DiskPageStore).   If we had called it HttpSessionPageStore, then it might
>> have been clearer what the class actually is.  you could also pretty
>> easily
>> modify it to be able to optionally store non-serialized Page objects so
>> that
>> people who, for whatever reason, cannot serialize their pages would not
>> have
>> to use the old HttpSessionStore (which i believe has some other problems).
>>
>> Having said that if you don't feel that it should go into wicket core,
>> then
>> it can quite happily live in the wicket tim and im not going to say any
>> more
>> on it :)
>>
>> However it still would be useful if
>> org.apache.wicket.protocol.http.pagestore.AbstractPageStore$SerializedPage
>> could implement IClusterable rather than Serializable as this will make
>> the
>> terracotta config simpler.
>>
>> Cheers,
>>
>> Richard
>> --
>> View this message in context:
>> http://www.nabble.com/Terracotta-integration-tp18168616p18378657.html
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>

[richardwilko]

Yea there is lots that is instrumented that now wont need to be.  

There are only 4 classes that need instrumenting for the page store; the 3 inner classes of TerrcottaPageStore, and $SerializedPage.  But im not sure what classes are needed for the other stuff thats stored in httpsession, like the actual Session (or user defined subclass) and the SessionBindingListener

Johan Compagner wrote:

In the current terracotta module will terracotta not monitor/instrument also
pages, components and models?

If we have this page store.. Then terracotta should only work on that page
store class right?
The rest is something that shouldnt be touched

johan


On Thu, Jul 10, 2008 at 12:40 PM, Ari Zilka <[e-mail]> wrote:

> 1. Can I get the tc-config.xml that goes with this
>
> 2. Terracotta TIMs can do almost anything we need to do here.  We can
> replace a method on class load.  We can probably pain $SerializedPage inner
> class to implement the IClusterable interface as well.  I dunno about
> removing Serializable though.  Would we have to?
>
> Anyways, if you ship me a list of what your ideal TIM would do I will get
> it configured, bundled in OSGi and back to you by Monday.
>
> I agree though.  The TIM could live at Terracotta's forge but should live
> with Wicket as it needs to be maintained with changes in Wicket moreso than
> changes in Terracotta.
>
> --Ari
>
>
> On Jul 10, 2008, at 1:58 AM, richardwilko wrote:
>
>
>> to use the new class you would put something like this in your application
>> class:
>>
>>        @Override
>>        public ISessionStore newSessionStore() {
>>                return new SecondLevelCacheSessionStore(this, new
>> TerracottaPageStore(100));
>>        }
>>
>> where the 100 is number of pages to keep as history, which is user defined
>> (please feel free comment on if you think we need a limit or not, or what
>> a
>> sensible number is).  There is also a default constructor which doesn't
>> impose a limit (it will store every page in the page map).  This
>> configurable limit means that we cant really override this method with the
>> asm stuff terracotta uses as is done currently.
>>
>> This means to use terracotta the user will need to add the wicket tim jar
>> file as a dependency to their project, so they can compile their code.
>>
>> However the main reason I thought it might be useful to add it into the
>> wicket source is because this page store may have other uses apart from
>> terracotta, it would be useful in any instance where DiskPageStore is not
>> suitable (disk access too slow or not allowed?  Probably not ever going to
>> be an issue I know and i'm certainly not suggesting that it should replace
>> DiskPageStore).   If we had called it HttpSessionPageStore, then it might
>> have been clearer what the class actually is.  you could also pretty
>> easily
>> modify it to be able to optionally store non-serialized Page objects so
>> that
>> people who, for whatever reason, cannot serialize their pages would not
>> have
>> to use the old HttpSessionStore (which i believe has some other problems).
>>
>> Having said that if you don't feel that it should go into wicket core,
>> then
>> it can quite happily live in the wicket tim and im not going to say any
>> more
>> on it :)
>>
>> However it still would be useful if
>> org.apache.wicket.protocol.http.pagestore.AbstractPageStore$SerializedPage
>> could implement IClusterable rather than Serializable as this will make
>> the
>> terracotta config simpler.
>>
>> Cheers,
>>
>> Richard
>> --
>> View this message in context:
>> http://www.nabble.com/Terracotta-integration-tp18168616p18378657.html
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>