Comments on: Apache Wicket Clustering With Multiple Options http://www.mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/ to our success! Mon, 30 Jan 2012 18:29:22 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: S http://www.mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/comment-page-1/#comment-3517 S Tue, 01 Nov 2011 22:03:51 +0000 http://wicketbyexample.com/?p=215#comment-3517 New to Wicket so a basic question. Is there a first level ie; L1 cache maintained by Wicket? If you are storing only one page per entry in SecondLevelCache, aren't you losing some of session data and hence resulting in not so good user experience? Or, is there a first level cache that will still save the whole page map? New to Wicket so a basic question. Is there a first level ie; L1 cache maintained by Wicket?
If you are storing only one page per entry in SecondLevelCache, aren’t you losing some of session data and hence resulting in not so good user experience? Or, is there a first level cache that will still save the whole page map?

]]> By: SM http://www.mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/comment-page-1/#comment-3516 SM Mon, 31 Oct 2011 17:01:58 +0000 http://wicketbyexample.com/?p=215#comment-3516 Can someone provide an example where I can use two Session Stores, one a local store that would cache all pages and second a clustered store that would cache only current page. If JVM running local store goes down and request is routed to another JVM within the cluster, application’s newSession() implementation should check clustered store and return current page. Can someone provide an example where I can use two Session Stores, one a local store that would cache all pages and second a clustered store that would cache only current page.

If JVM running local store goes down and request is routed to another JVM within the cluster, application’s newSession() implementation should check clustered store and return current page.

]]> By: Dmitry http://www.mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/comment-page-1/#comment-3515 Dmitry Wed, 26 May 2010 20:19:36 +0000 http://wicketbyexample.com/?p=215#comment-3515 Hey, what a great post. But I still have a question. I tried to apply the code "as is" to my Wicket app. I started 2 instances of web server behind the haproxy to see what will happen. But I get 'Page Expired' exception (especially on an Ajax request) when a request hits second instance. The problem (traced down) is in this line: IPageMap pageMap = session.pageMapForName(requestParameters.getPageMapName(), false); The PageMap returned from the session is null. Is extra configuration needed for your clustering solution to work? The Session.(IPageMap)getAttribute(attributeForPageMapName(pageMapName)); simply returns null for the second web server instance. Any suggestions would be really appreciated. Hey, what a great post.

But I still have a question. I tried to apply the code “as is” to my Wicket app.
I started 2 instances of web server behind the haproxy to see what will happen.
But I get ‘Page Expired’ exception (especially on an Ajax request) when a request hits second instance.
The problem (traced down) is in this line:
IPageMap pageMap = session.pageMapForName(requestParameters.getPageMapName(), false);

The PageMap returned from the session is null.
Is extra configuration needed for your clustering solution to work? The

Session.(IPageMap)getAttribute(attributeForPageMapName(pageMapName));

simply returns null for the second web server instance.

Any suggestions would be really appreciated.

]]> By: Ondra http://www.mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/comment-page-1/#comment-3514 Ondra Fri, 07 May 2010 03:21:44 +0000 http://wicketbyexample.com/?p=215#comment-3514 [1] http://wicketbyexample.com/api/wicket/1.4.5/org/apache/wicket/protocol/http/SecondLevelCacheSessionStore.IPageStore.html#storePage%28java.lang.String,%20org.apache.wicket.Page%29 [1] http://wicketbyexample.com/api/wicket/1.4.5/org/apache/wicket/protocol/http/SecondLevelCacheSessionStore.IPageStore.html#storePage%28java.lang.String,%20org.apache.wicket.Page%29

]]> By: Ondra http://www.mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/comment-page-1/#comment-3513 Ondra Fri, 07 May 2010 03:21:12 +0000 http://wicketbyexample.com/?p=215#comment-3513 Does that really work? I don't see any code for this [1]: """Note that the versionNumber and ajaxVersionNumber parameters may be -1. * 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. """ Here is my untested implementation with Infinispan (JBoss Cache): http://ondra.zizka.cz/stranky/programovani/java/web/wicket/wicket-pagestore-jbosscache-infinispan-integration.texy Does that really work? I don’t see any code for this [1]:

“”"Note that the versionNumber and ajaxVersionNumber parameters may be -1.
* 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. “”"

Here is my untested implementation with Infinispan (JBoss Cache):
http://ondra.zizka.cz/stranky/programovani/java/web/wicket/wicket-pagestore-jbosscache-infinispan-integration.texy

]]> By: Martin Grotzke http://www.mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/comment-page-1/#comment-3512 Martin Grotzke Sun, 28 Feb 2010 00:32:57 +0000 http://wicketbyexample.com/?p=215#comment-3512 I created the memcached-session-manager ([1]) which is a session manager for tomcat that replicates sessions to memcached nodes for session failover. There are different serialization strategies available ([2]), besides default java serialization I wrote an xml based serialization (using javolution) which has the advantage, that it supports different class versions (useful for a new deployment of your application). Right now I'm implementing a feature so that sessions are only replicated if they are modified so that readonly requests don't cause a session replication. I created the memcached-session-manager for a wicket application that needs to be highly scalable, and I created a very simple wicket app for performance comparison of the different serialization strategies. I still need to extend this benchmark app (and add it to the github repo), but there's already a wiki page with a rough overview over the current results - with an older version of msm without the replicate-only-modified-sessions-feature ([3]). Cheers, Martin [1] http://code.google.com/p/memcached-session-manager/ [2] http://code.google.com/p/memcached-session-manager/wiki/SerializationStrategies [3] http://code.google.com/p/memcached-session-manager/wiki/Performance I created the memcached-session-manager ([1]) which is a session manager for tomcat that replicates sessions to memcached nodes for session failover.

There are different serialization strategies available ([2]), besides default java serialization I wrote an xml based serialization (using javolution) which has the advantage, that it supports different class versions (useful for a new deployment of your application).

Right now I’m implementing a feature so that sessions are only replicated if they are modified so that readonly requests don’t cause a session replication.

I created the memcached-session-manager for a wicket application that needs to be highly scalable, and I created a very simple wicket app for performance comparison of the different serialization strategies. I still need to extend this benchmark app (and add it to the github repo), but there’s already a wiki page with a rough overview over the current results – with an older version of msm without the replicate-only-modified-sessions-feature ([3]).

Cheers,
Martin

[1] http://code.google.com/p/memcached-session-manager/
[2] http://code.google.com/p/memcached-session-manager/wiki/SerializationStrategies
[3] http://code.google.com/p/memcached-session-manager/wiki/Performance

]]> By: phil http://www.mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/comment-page-1/#comment-3511 phil Wed, 24 Feb 2010 11:17:34 +0000 http://wicketbyexample.com/?p=215#comment-3511 FYI, I think you should add ":" to the sessionId test in unbind : public void unbind(final String sessionId) { IMap map = client.getMap(mapName); for (String key : map.keySet()) { if (key.startsWith(sessionId+":")) { map.remove(key); } } } And maybe you should define a constant named DELIMITER... and hope that it never happens elsewhere... FYI, I think you should add “:” to the sessionId test in unbind :
public void unbind(final String sessionId) {
IMap map = client.getMap(mapName);
for (String key : map.keySet()) {
if (key.startsWith(sessionId+”:”)) {
map.remove(key);
}
}
}

And maybe you should define a constant named DELIMITER… and hope that it never happens elsewhere…

]]> By: kinabalu http://www.mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/comment-page-1/#comment-3510 kinabalu Sat, 13 Feb 2010 22:29:28 +0000 http://wicketbyexample.com/?p=215#comment-3510 I believe Hazelcast will handle that for you automatically, you can set up different caching structures in your Hazelcast configuration so that older caches get expired, and also set a max so once it reaches a certain point if you haven't got a persistence mechanism, it'll drop the oldest. I believe Hazelcast will handle that for you automatically, you can set up different caching structures in your Hazelcast configuration so that older caches get expired, and also set a max so once it reaches a certain point if you haven’t got a persistence mechanism, it’ll drop the oldest.

]]> By: victori http://www.mysticcoders.com/blog/apache-wicket-clustering-with-multiple-options/comment-page-1/#comment-3509 victori Sat, 13 Feb 2010 21:22:10 +0000 http://wicketbyexample.com/?p=215#comment-3509 There is a bit more to it. The reason my pagestore is so simple is the fact I offload the complexity to memcached. Memcached prematurely expires older caches automatically when it needs room for more space. Last I checked I don't know of any Java caching implementation that expires caches prematurely like memcached. There is a bit more to it. The reason my pagestore is so simple is the fact I offload the complexity to memcached. Memcached prematurely expires older caches automatically when it needs room for more space. Last I checked I don’t know of any Java caching implementation that expires caches prematurely like memcached.

]]>