Chris’ Musings

Actually, it wasn’t too bad once I worked through how I wanted to load test a GWT app. We have lots of tests for the GUI portion which obviously also test the RPC/server side; but we wanted to really stress test a few RPC paths.

Fortunately, we are not the first. We needed a mechanism to simulate RPC calls and with a little digging (actually, it was pretty hidden in a mess of less than helpful posts), we found a rough and ready class that we used – easier to borrow something than to build from scratch. Here is the project page:

http://code.google.com/p/gwt-syncproxy/

Once we adapted the code to our specific case and removed the app engine stuff, we were good to go with a quick framework that lets us write RPC test cases that look like:

RPCService service = 
       (RPCService ) SyncProxy.newProxyInstance(RPCService.class, 
                                                "http://mydomain/my-web-app/",
                                                "path");
String result = service.executeRemoteMethod(param1, param2);

We use the SyncProxy to instantiate the RPC service, than call a method on the service interface and wait for the result. That’s my definition of easy to use. The great thing is the test code is synchronized so we don’t have to worry about ansyc calls in the test code and can evaluate the result for correctness immediately.

Next up is to use Apache JMeter to simulate load. This again is relatively easy. By implementing the JavaSamplerClient of JMeter, we can add our test case as a java class that gets executed. There is sample code available – take a look at SleepTest included in the source download.

We did have to modify the source code to add the ability to include the CookieManager in the JavaSamplerClient. This required a bit more digging around and modifying of JMeter but is doable in an hour or so and changes 3-4 JMeter files in the java protocol package. If you want to do this, look at the HTTP protocol package. We did this because our code retrieves cookies via a standard HTTP call first and then calls our java test case which needs to access the cookies. Other than that, we used the stock framework and can easily load test our app.

In fact, with these two pieces (SyncProxy and JavaSamplerClient) we quickly write test cases for the critical parts of our app that we want to load test. That’s my task for next week – yeah!

The great part is after a day of testing different components, our performance and scalability is even greater than what we thought it was (ok we did make one minor change to remove some contention) and we have lots of room for growth with our current architecture.

The only part I couldn’t figure out was how to get JMeter to add our jar files to it’s internal classpath. We tried using the search_paths and user.classpath parameters, but nothing we did seemed to allow JMeter to pickup our jars from a different location. It’s just an annoyance to have to build the components and then move the jars to the ext directory of JMeter. Would be nice if we could get the search_paths parameter working. Oh well, maybe another day.

All in all, it took about a day to become familiar with these tools and write our test cases to cover our most frequently used code paths.

How to tell if the server side is running in the hosted mode. A quick an dirty way I found was to check for the request gwt.codesvr.

Why would you want to do this. Actually, we generate the hosted.html file in a servlet and some of the embedded items change based on whether we are in a live app server or the hosted one.

Also, GWT.script() only works on the client side. Would have been nice to use this on the server side also.

We want to let our customers host a form on their web pages (so they can control the form L&F using whatever mechanism they want) and “post” the form to our servers. We also want to provide robust validation and error handling for the form. We created a little gwt app that can be downloaded (cross site script).

Everything worked great until we tried to post the results to our server (actually that worked) and get a result back to show to the user (this didn’t work). Getting the result back turned out to be really hard. We first tried to use a gwt form and modified the form to use the window.name tricks for the returned value; but couldn’t get it to work in all of the browsers. It was probably a mistake on our part; but after a couple of hours we did not get it to work.

So we ended up crafting a specific URL with the form fields as parameters, redirecting the browser to that URL and then the server “redirects” the user to the next page on success or back to the form page on error (with parameter values appended that the gwt app can read and display error message for).

We’re not entirely happy with the solution as there is a lot going on in the address bar; but it works.

We will revisit this shortly and try to get the window.name trick working. In the meantime I would like to hear about others experiences.

Now that GWT 2.0 is out, I want to take the new panels for a spin.

We have been upgrading our UI with the pre 2.0 widgets. Now I want to try the tab panel. We have spent a lot of time trying to get an X icon in the upper right. Hopefully it will be easier with the the widget.

For our internally developed application framework for GWT apps, we want to use RunAsync heavily. We have pushed as much common code to the framework as possible (that’s what frameworks are there for). So developing new screens is really a breeze. Anyway, we wanted to push the RunAsync into the framework so that developers don’t have to think or even now about it.

However, this doesn’t seem possible with the current implementation. Basically, the split point is where the physicaly code split occurs. Which is logical. We were hoping that a class hierarchy would be taken into account. For example:

public abstract class AbstractClass {
 
  public abstract void doActualWork(Callback cb);
 
  public void doAsyncCall(final Callback cb){
      GWT.runAsync(new RunAsyncCallback(){
         public void onFailure(Throwable err){
            Window.alert("code download failure");
         }
 
         public void onSuccess(){
            doActualWork(cb);
         }
      });
  }
 
}
 
public class FirstClass extends AbstractClass{
   public void doActualWork(Callback cb){
     //does actually work and calls Callback
   }
 
}
 
public class SecondClass extends AbstractClass{
   public void doActualWork(Callback cb){
     //does some other actually work and calls Callback
   }
 
}

When I have the concrete implementation of doAsyncCall(Callback cb) in
AbstractClass, I get 1 split point. When I move the implementation to
each of the sub classes (making the method abstract in AbstractClass),
I get two split points.

Don’t get me wrong, we love the new feature. Here’s hoping for a future enhancement So for now, I guess every developer will need to know about split points. Not a big deal, just one more thing to remember.