News: Apache Wicket Clustering With Multiple Options
We’ve been seeing more and more implementations of IPageStore out in the wild for Apache Wicket. The interface basically decides how Wicket will store the Pagemap for your application. The default that ships with Wicket uses DiskPageStore which is an implementation that stores the serialized pages grouped in a single file per pagemap. After reading a wonderful blog post on Letsgetdugg a few days ago: Clustering Wicket for fun and profit!, I decided to take a look at writing an implementation using Hazelcast – an “open source clustering and highly scalable data distribution platform”. The implementation below borrows heavily from Victor. It basically creates a HazelcastInstance in the constructor and then overrides all the methods necessary from AbstractPageStore. Take a look at the rest of the article to see the code behind a Hazelcast based page store.
- Posted by: Andrew Lombardi
- Posted on: February 23 2010 03:59 EST
- Re: Apache Wicket Clustering With Multiple Options by Istvan Soos on February 23 2010 09:06 EST
- Re: Apache Wicket Clustering With Multiple Options by Jan de Jonge on February 23 2010 15:10 EST
- Re: Apache Wicket Clustering With Multiple Options by Troll McTroll on February 25 2010 07:42 EST
- Re: Apache Wicket Clustering With Multiple Options by null on February 25 2010 12:31 EST
- What performance problem by x y on February 24 2010 05:31 EST
- food for thought by mike green on July 02 2010 04:43 EDT
Cool. I like this combination :)
Yet another area where Wicket shines in the Web framework arena. The last time I checked Tapestry was doing very, very badly in this area. Even performance was a very serious issue in the latest Tapestry 5 release. Many companies I know that have used Tapestry in their last projects are ruling it out completely for future projects. It's sad Tapestry is dying this way. It was once a very good framework that I loved. Jan
The last time I checked Wicket was doing very, very badly in all areas. Even performance was a very serious issue in the latest Wicket 1.4 release. Many companies I know that have used Wicket in their last projects are ruling it out completely for future projects. It's sad Wicket is dying this way. It was once a very good framework that I loved.
I find that in the US people or more open to people of any age who can do the job. I've literally hear manager folks say in Holland that coders that are older than 30(!) are losers who didn't make it to management. That same company had the hiring policy of getting people straight from colleague so that it 'would be easier to incorporate them in your culture and older people became to rigid in their views anyway'. It's sad, because there are plenty of enthusiastic coders in Holland but this culture of middle-management doesn't do much for 'coding as a career'. Moving to the US has been very refreshing to me in that respect, and I have coder colleagues of all ages now, who I feel are respected for what they deliver rather than their age.
Ugh wtf, this reply was meant for a whole other thread. TSS weirdness! For this thread: I haven't been aware complaints of people about degrading performance in Wicket 1.4 etc. Sounds very much like a Troll to me.
definitely a troll Eelco. the name was "Troll McTroll"
In my former company I worked with Jan de Jonge. He told me once that he knows that Tapestry 5 is the best web framework out there, but he doesn't want anyone else to know it so he can always be few steps above his competition. He also confessed that he will constantly bash it on forums hoping that way to distract others from using it. He also said he will deny his intentions if somebody ever disclose it to public. BTW, congrats to Wicket! Very good framework also.
I really like component based frameworks and Wicket is a lovely bit of software but this is a performance issue that needs more highlighting. Managing the UI component tree on the server side has this problem that request based frameworks (struts etc) and client side frameworks (flex, GWT) dont. By the same token GWT etc dont make it clear how expensive (and how much care) it is to make a server side call (that is not a problem at all for Wicket). Not an easy decision to make between client side vs server side. For me request vs component is very easy ;)
Hey, what a great post. But I still have a question. I tried to apply the code “as is” to my Wicket app after I read the article http://www.pdfok.com/watch/seam-reference.pdf-8763532.html . 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.