Redirect after POST - a performance issue?

On a web application, I am currently working on for a client, we discussed implementing the redirect after post pattern. The web framework in action is Struts 1.2.

During the discussion performance was brought up as a problem for implementing redirect after post. I haven't thought of before that redirecting after a post could be a performance issue...?

Well you do double the number of requests per client since the server asks the client to redirect. With 400 concurrent users posting that would end up in 800 requests. A problem? Maybe, but you do need to have the scalability in your application.

This potentially performance issue needs to be evaluated against the benefits of using the pattern since you can avoid some nasty situations for example where users a refreshing a page or using the back button.

So anybody out there having any experience or other comments about this subject? Anybody done some analysis of the consequences of actually implementing the redirect after post pattern? Your comments would be much appreciated.

Up and running with GWT and Maven 2

I have decided that it was time for me to take a look a Google Web Toolkit. In this post I will share my experiences with setting up my build using Maven 2 (do we really still need to version the maven name? Anybody starting new projects using Maven 1?).

You may see following posts about my GWT experiences as my, in the moment, experimenting application evolves to take over the world...

To start somewhere I found a Maven 2 GWT archetype which I gave a try. I found the archetype through a Google Group so you need to download the archetype from here and build it. Just unzip and run mvn install.

The archetype is designed for use inside Eclipse. My favorite IDE is Intellij IDEA, but never mind the Eclipse files .project, .classpath and a .launch file can just be deleted.

With the magic line(s) beautifully expressed in a non verbose way ;-) I created my project:

mvn archetype:create -DarchetypeGroupId=com.totsp.gwt -DarchetypeArtifactId=gwt-archetype -DarchetypeVersion=1.0-SNAPSHOT -DartifactId=foobar -DgroupId=foo.bar

The archetype in use uploaded the 12. of June references the latest stabile release of GWT version 1.3.3. In the time of writing there is a version 1.4 RC (1.4.10). I updated my pom.xml to point to this new version.

For interaction with GWT through maven I have used the plugin as provided with the archetype maven-googlewebtoolkit2-plugin.

Simply add something like the following to your settings.xml:

<profile>
<id>gwt-1.4.10</id>
<properties>
<google.webtoolkit.home>/usr/local/gwt/gwt-mac-1.4.10</google.webtoolkit.home>
<google.webtoolkit.extrajvmargs>-XstartOnFirstThread</google.webtoolkit.extrajvmargs>
</properties>
</profile>

and remember to activate the profile for your build. This will also let the plugin be aware of where your local GWT installation is. If you are running on Mac OS X, as I am, remember to set -XstartOnFirstThread. Otherwise the GWT browser cannot start.

Having this in place I was able to start my build by running 'mvn gwt:gwt'. This goal runs just after the Maven package phase and will start the GWT browser launching my app.


Thanks to the archetype I was up running in no time. It gives me a head start in how to organize my project structure and has some important initial configurations for the gwt plugin. Of course I have not yet tried the full capabilities (or lacking) of the various goals of the plugin.

I also tried using the maven jetty plugin and this worked for me NOT using the mvn jetty:run, but the mvn jetty:run-exploded goal. Using the run-exploded goal lets maven run the war plugin and Jetty will look in the target folder and not directly in the source folders. Not sure yet why looking directly in the source folders causes some GWT problems, but for now I will just use jetty towards the exploded war in the target folder.

In time I will found out how good my development cycle will be when beginning to actually add code to the application...