You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Josh Kamau <jo...@gmail.com> on 2010/04/08 09:00:30 UTC
Wicket And GAE
What are the main issues with wicket and Google app engine
Re: Wicket And GAE
Posted by Juha Palomäki <ju...@gmail.com>.
I think the main issue is that for the development mode you need to
disable resource polling, since that is using threads (which are not
supported in GAE). This is described here:
http://stronglytypedblog.blogspot.com/2009/04/wicket-on-google-app-engine.html
One "problem" with this is that this obviously disables the resource
reloading, which might be slightly annoying when developing. There
might be more elegant solutions to this, but in order to overcome this
I wrote my own ModificationWatcher implementation (see code below). My
own modificationwatcher does not use threads, instead you must
manually call it every now and then so that it will see if the
resources have been changed.
In order to use my StaticModificationWatcher, you need to include the
following stuff in your Wicket Application class.
@Override
protected void init() {
super.init();
// your standard init stuff goes here
if("development".equalsIgnoreCase(getConfigurationType())) {
staticModificationWatcher = new StaticModificationWatcher();
getResourceSettings().setResourceWatcher(staticModificationWatcher);
getResourceSettings().setResourcePollFrequency(Duration.ONE_SECOND);
getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl(true);
} else {
getResourceSettings().setAddLastModifiedTimeToResourceReferenceUrl(false);
getResourceSettings().setResourcePollFrequency(null);
}
@Override
public RequestCycle newRequestCycle(Request request, Response response) {
// In deploymentmode we are not using the staticModificationWatcher
if(staticModificationWatcher != null) {
staticModificationWatcher.RunCheck();
}
return super.newRequestCycle(request, response);
}
And the StaticModicationWatcher.java
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;
import org.apache.wicket.util.listener.ChangeListenerSet;
import org.apache.wicket.util.listener.IChangeListener;
import org.apache.wicket.util.time.Duration;
import org.apache.wicket.util.time.Time;
import org.apache.wicket.util.watch.IModifiable;
import org.apache.wicket.util.watch.IModificationWatcher;
public class StaticModificationWatcher implements IModificationWatcher {
private static StaticModificationWatcher instance;
private static final class Entry {
// The most recent lastModificationTime polled on the object
Time lastModifiedTime;
// The set of listeners to call when the modifiable changes
final ChangeListenerSet listeners = new ChangeListenerSet();
// The modifiable thing
IModifiable modifiable;
}
private Map<IModifiable, Entry> listeners;
/**
* Call this method regularly
*/
public void RunCheck() {
// Use a separate list to avoid concurrent modification exceptions (notifying
// the listener might cause a call to the add -method of this class)
Collection<ChangeListenerSet> toBeNotified = new
ArrayList<ChangeListenerSet>();
for(Entry entry : listeners.values()) {
if(entry.modifiable.lastModifiedTime().equals(entry.lastModifiedTime)
== false) {
toBeNotified.add(entry.listeners);
// entry.listeners.notifyListeners();
}
entry.lastModifiedTime = entry.modifiable.lastModifiedTime();
}
for(ChangeListenerSet changeListenerSet : toBeNotified) {
changeListenerSet.notifyListeners();
}
}
public StaticModificationWatcher() {
listeners = Collections.synchronizedMap(
new HashMap<IModifiable, Entry>());
}
@Override
public boolean add(IModifiable modifiable, IChangeListener listener) {
boolean contains = listeners.containsKey(modifiable);
if(contains == false) {
Entry entry = new Entry();
entry.modifiable = modifiable;
entry.lastModifiedTime = modifiable.lastModifiedTime();
listeners.put(modifiable, entry);
}
listeners.get(modifiable).listeners.add(listener);
return contains;
}
@Override
public void destroy() {
// nothing to do
}
@Override
public Set<IModifiable> getEntries() {
return listeners.keySet();
}
@Override
public IModifiable remove(IModifiable modifiable) {
listeners.remove(modifiable);
return modifiable;
}
@Override
public void start(Duration duration) {
// ignored
}
}
On Thu, Apr 8, 2010 at 12:43 PM, nino martinez wael
<ni...@gmail.com> wrote:
> ery describing mail. But AFAIK, and my knowledge are rather
> limited you need to switch the session store. And then GAE has a
> couple of restrictions for java that you need to comply with. It's not
> so much Wicket and GAE, but JAVA and GAE that have issues.. Other than
> that search with google for Wicket and GAE, theres a couple of
> tutorials out there.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket And GAE
Posted by nino martinez wael <ni...@gmail.com>.
Hi
Not a very describing mail. But AFAIK, and my knowledge are rather
limited you need to switch the session store. And then GAE has a
couple of restrictions for java that you need to comply with. It's not
so much Wicket and GAE, but JAVA and GAE that have issues.. Other than
that search with google for Wicket and GAE, theres a couple of
tutorials out there.
regards Nino
2010/4/8 Josh Kamau <jo...@gmail.com>:
> What are the main issues with wicket and Google app engine
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket And GAE
Posted by Josh Kamau <jo...@gmail.com>.
Thanks so much Rich for that information .I kept getting the Deserialization
errors . Am a using Guice and JPA alongside wicket. I have since given up on
using GAE and am shopping for a VPS or servlet hosting.
Regards.
Josh
On Tue, Apr 13, 2010 at 4:51 AM, Richard Nichols <rn...@richardnichols.net>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 <jo...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket And GAE
Posted by Martijn Dashorst <ma...@gmail.com>.
On Tue, Apr 13, 2010 at 6:12 PM, marc fawzi <ma...@gmail.com> wrote:
> Is there an IRC channel for Wicket users or is this the best place for
> newbies like me to post questions and get help?
Both. ##wicket on freenode.net is the official wicket IRC channel, and
you're welcome to ask and answer here :)
Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket And GAE
Posted by marc fawzi <ma...@gmail.com>.
<<
Per #1, the GAE people highly discourage pinging to keep the instance alive.
Also, I tried it for a bit anyways, and it didn't help. I get instance
restarts in the MIDDLE of page loads (hint hint: I could use help on my
other post!). The thing to realize with GAE is that you need to keep
everything out of your Application init().>>
It works perfectly for me. It's not so much "pinging" since you're not
"pinging" a port. It's actually getting the servlets to stay loaded and the
trick is to generate *enough cpu usage* not just *enough traffic* (my JVM
stays hot for about 2% of the cpu daily quota). For example, loading a very
simple page once every 10 seconds may not keep your JVM hot. Loading a more
complex page once every 10 seconds will keep it hot. Also, you need to give
the GAE some time to adjust to the new cpu load before it stops unloading
your servlets. I've got the graphs to prove it :)
Anyway, I don't really care what the GAE people say. They have a problem to
solve, especially for the heavier frameworks like Grails.
On Wed, Apr 14, 2010 at 6:07 AM, jbrookover <jb...@cast.org> wrote:
>
> Per #1, the GAE people highly discourage pinging to keep the instance
> alive.
> Also, I tried it for a bit anyways, and it didn't help. I get instance
> restarts in the MIDDLE of page loads (hint hint: I could use help on my
> other post!). The thing to realize with GAE is that you need to keep
> everything out of your Application init().
>
> It takes some effort, but you can get pretty good Wicket apps running on
> GAE. It's certainly a lot harder, though, than running it on your own.
>
> Jake
>
>
> marc fawzi wrote:
> >
> > Hey guys
> >
> > I'm new to Wicket
> >
> > I've made two discoveries with respect to GAE and Wicket:
> >
> > 1. I figured out how to keep my GAE app instance hot at all times (well,
> > at
> > least for 99.9% of the time.. the GAE still produces "transient errors"
> > every now and then) -- It's really simple: just have a script that
> > launches
> > a new task every 12 seconds and set the task url to a url that is routed
> > to/handled by the script itself then when the script runs again (in this
> > way) it will do two things: 1) urlfetch a url that is handled by the app
> > you
> > wish to keep hot (which is on another *.appspot.com url) and 2) starts
> > schedule another task in 12 seconds. Infinite task loop. Google does kill
> > the task loop eventually so then you need a cron job to run every 1 hour
> > to
> > restart the script :) and that's it.
> >
> > 2. Someone (srfarley) is working on a version of Wicket for GAE:
> >
> > "This project provides a template to help you get started with building a
> > Wicket <http://wicket.apache.org/> application for Google App
> > Engine<http://code.google.com/appengine/>.
> > It is a re-implementation of the Guestbook application described by the
> > App
> > Engine tutorial
> > <http://code.google.com/appengine/docs/java/gettingstarted/>.
> > Whereas the tutorial uses raw servlets and JSP to demonstrate a some of
> > the
> > basic features of App Engine, this project uses Wicket as the web
> > framework.
> >
> >
> > In addition, the project defines classes for handing persistence using
> > JDO<http://code.google.com/appengine/docs/java/datastore/>,
> > and uses Google Guice <http://code.google.com/p/google-guice/> to inject
> > instances of these classes into the Wicket pages for interacting with the
> > App Engine datastore.
> >
> > For unit testing, the project contains base classes that set up the App
> > Engine development environment so you can write tests against the full
> > stack, including those that interact directly with the Wicket pages. The
> > testing framework is TestNG <http://testng.org/doc/index.html>, but it
> is
> > possible to convert them to JUnit tests with some work."
> >
> > http://code.google.com/p/wicket-gae-template/
> >
> > Given that I've never used Wicket (I looked at a couple examples so far)
> > I'm
> > hoping that we can help each other as we attempt to get good outcome for
> > our
> > Wicket+GAE implementations .... To make things more challenging, I'm
> using
> > Scala, which I've never run on GAE before and I'm also new to it :)
> >
> > Is there an IRC channel for Wicket users or is this the best place for
> > newbies like me to post questions and get help?
> >
> > Thanks,
> >
> > Marc
> >
> > On Tue, Apr 13, 2010 at 6:20 AM, jbrookover <jb...@cast.org> wrote:
> >
> >>
> >> 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 <jo...@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-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Wicket-And-GAE-tp28174925p28242292.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket And GAE
Posted by jbrookover <jb...@cast.org>.
Per #1, the GAE people highly discourage pinging to keep the instance alive.
Also, I tried it for a bit anyways, and it didn't help. I get instance
restarts in the MIDDLE of page loads (hint hint: I could use help on my
other post!). The thing to realize with GAE is that you need to keep
everything out of your Application init().
It takes some effort, but you can get pretty good Wicket apps running on
GAE. It's certainly a lot harder, though, than running it on your own.
Jake
marc fawzi wrote:
>
> Hey guys
>
> I'm new to Wicket
>
> I've made two discoveries with respect to GAE and Wicket:
>
> 1. I figured out how to keep my GAE app instance hot at all times (well,
> at
> least for 99.9% of the time.. the GAE still produces "transient errors"
> every now and then) -- It's really simple: just have a script that
> launches
> a new task every 12 seconds and set the task url to a url that is routed
> to/handled by the script itself then when the script runs again (in this
> way) it will do two things: 1) urlfetch a url that is handled by the app
> you
> wish to keep hot (which is on another *.appspot.com url) and 2) starts
> schedule another task in 12 seconds. Infinite task loop. Google does kill
> the task loop eventually so then you need a cron job to run every 1 hour
> to
> restart the script :) and that's it.
>
> 2. Someone (srfarley) is working on a version of Wicket for GAE:
>
> "This project provides a template to help you get started with building a
> Wicket <http://wicket.apache.org/> application for Google App
> Engine<http://code.google.com/appengine/>.
> It is a re-implementation of the Guestbook application described by the
> App
> Engine tutorial
> <http://code.google.com/appengine/docs/java/gettingstarted/>.
> Whereas the tutorial uses raw servlets and JSP to demonstrate a some of
> the
> basic features of App Engine, this project uses Wicket as the web
> framework.
>
>
> In addition, the project defines classes for handing persistence using
> JDO<http://code.google.com/appengine/docs/java/datastore/>,
> and uses Google Guice <http://code.google.com/p/google-guice/> to inject
> instances of these classes into the Wicket pages for interacting with the
> App Engine datastore.
>
> For unit testing, the project contains base classes that set up the App
> Engine development environment so you can write tests against the full
> stack, including those that interact directly with the Wicket pages. The
> testing framework is TestNG <http://testng.org/doc/index.html>, but it is
> possible to convert them to JUnit tests with some work."
>
> http://code.google.com/p/wicket-gae-template/
>
> Given that I've never used Wicket (I looked at a couple examples so far)
> I'm
> hoping that we can help each other as we attempt to get good outcome for
> our
> Wicket+GAE implementations .... To make things more challenging, I'm using
> Scala, which I've never run on GAE before and I'm also new to it :)
>
> Is there an IRC channel for Wicket users or is this the best place for
> newbies like me to post questions and get help?
>
> Thanks,
>
> Marc
>
> On Tue, Apr 13, 2010 at 6:20 AM, jbrookover <jb...@cast.org> wrote:
>
>>
>> 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 <jo...@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-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
--
View this message in context: http://old.nabble.com/Wicket-And-GAE-tp28174925p28242292.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket And GAE
Posted by marc fawzi <ma...@gmail.com>.
Hey guys
I'm new to Wicket
I've made two discoveries with respect to GAE and Wicket:
1. I figured out how to keep my GAE app instance hot at all times (well, at
least for 99.9% of the time.. the GAE still produces "transient errors"
every now and then) -- It's really simple: just have a script that launches
a new task every 12 seconds and set the task url to a url that is routed
to/handled by the script itself then when the script runs again (in this
way) it will do two things: 1) urlfetch a url that is handled by the app you
wish to keep hot (which is on another *.appspot.com url) and 2) starts
schedule another task in 12 seconds. Infinite task loop. Google does kill
the task loop eventually so then you need a cron job to run every 1 hour to
restart the script :) and that's it.
2. Someone (srfarley) is working on a version of Wicket for GAE:
"This project provides a template to help you get started with building a
Wicket <http://wicket.apache.org/> application for Google App
Engine<http://code.google.com/appengine/>.
It is a re-implementation of the Guestbook application described by the App
Engine tutorial <http://code.google.com/appengine/docs/java/gettingstarted/>.
Whereas the tutorial uses raw servlets and JSP to demonstrate a some of the
basic features of App Engine, this project uses Wicket as the web framework.
In addition, the project defines classes for handing persistence using
JDO<http://code.google.com/appengine/docs/java/datastore/>,
and uses Google Guice <http://code.google.com/p/google-guice/> to inject
instances of these classes into the Wicket pages for interacting with the
App Engine datastore.
For unit testing, the project contains base classes that set up the App
Engine development environment so you can write tests against the full
stack, including those that interact directly with the Wicket pages. The
testing framework is TestNG <http://testng.org/doc/index.html>, but it is
possible to convert them to JUnit tests with some work."
http://code.google.com/p/wicket-gae-template/
Given that I've never used Wicket (I looked at a couple examples so far) I'm
hoping that we can help each other as we attempt to get good outcome for our
Wicket+GAE implementations .... To make things more challenging, I'm using
Scala, which I've never run on GAE before and I'm also new to it :)
Is there an IRC channel for Wicket users or is this the best place for
newbies like me to post questions and get help?
Thanks,
Marc
On Tue, Apr 13, 2010 at 6:20 AM, jbrookover <jb...@cast.org> wrote:
>
> 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 <jo...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket And GAE
Posted by jbrookover <jb...@cast.org>.
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 <jo...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket And GAE
Posted by Richard Nichols <rn...@richardnichols.net>.
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 <jo...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org