I'm pretty committed to a project using Wicket on GAE. I haven't encountered any deserialization issues that people have been bringing up, which makes me worry a bit since I've encountered (and dealt with) a slew of other issues :)
Regarding the HttpSessionStore, I discovered a bad coding practice of mine when every single session entry in the datastore was 500KB+. Once I resolved that issue, using more transient fields and detachable models, I'm relatively happy with the results. GAE, by default, uses the MemCache to implement this feature so it should be relatively speedy. It's no different from any other application storing data in the javax.servlet.http.HttpSession. My only lingering problem (another thread here) is that GAE can trash your application instance at any point. If you are relying on SharedResources, those can go away - even in the middle of an active page load, potentially breaking some links. Currently looking for a way around that :) Jake Richard Nichols-3 wrote: > > Biggest problem, and IMO a show stopper, is the Serialization issues. > > Since Wicket serializes session data (pagemap etc) you have to enable > the GAE session-store to get wicket working correctly on GAE. > > GAE clusters sessions by writing them to the GAE data store to spread > the session across the cluster - and writes are *slow*. > > Worse though, if you create an incompatible change to a serialized > page/component/model, when that user returns to your application, GAE > will quietly fail and the user will get a blank page. Checking the GAE > error log reveals a deserialization error in the core GAE engine. > > This is because the session reserialization in GAE is handled at the > GAE/Jetty level and any error in reconsitution of the error currently > breaks GAE completely. Google has acknowledged this problem, but for > most frameworks it's not a big deal as you don't store large Objects > in the HttpSession. > > I had planned to deploy the site I'm currently working on > http://www.onmydoorstep.com.au/ on GAE but after a few weeks of > running the prototypes on GAE, I found the performance to be too poor > and the infrastructure too flakey for a production site. > > NB - It's certainly possible to create high-performance/reliable sites > using GAE/J, but Wicket is not a suitable framework due to the > Serialization data store write problem. > > Even if the performance were better and the deserialization issue was > fixed, you would blow through your data store quota in no-time due to > the amount of data store in the session. > > If anyone has solutions or further experience with these issues - I'm > all ears! :) > > cheers, > Rich > > On 8 April 2010 17:00, Josh Kamau <joshnet2...@gmail.com> wrote: >> What are the main issues with wicket and Google app engine >> > > > > -- > Richard Nichols :: http://www.visural.com/ :: > http://www.richardnichols.net/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://old.nabble.com/Wicket-And-GAE-tp28174925p28229863.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
