On Thu, Feb 5, 2009 at 5:38 PM, otismo <[email protected]> wrote:
> Apparently, I'm search-challenged 'cause I spend 45 minutes looking
> before I posted and another 1/2 hour now, searching for things like:
> custom serialization
> client serialization
> requestbuilder sendrequest
> streamserializationwriter
> requestbuilder requestbuilder.post
>
> Maybe you could throw me a bone here? :)  Do I have to use JSON?

I tried "jmeter load testing" and got the following.  I didn't read
any of the resulting posts, so they may or may not be relevant....

http://groups.google.com/group/Google-Web-Toolkit/search?hl=en&group=Google-Web-Toolkit&q=jmeter+load+testing&qt_g=Search+this+group

>> I'd bet that, if you solved this problem in an orthogonal fashion, you'd 
>> have yourself a pretty successful open source project on your hands.
>
> Are you saying there's no easy way then?

Yes, there's no easy way.

First, the client-server and server-client wire formats are different.
 Not really a "problem", just a complicating factor.

More of a problem is the fact that the client-side code (both
serialization and deserialization) relies on JSNI.  That means one of
two things: you either have to provide an environment in which JSNI
can be executed so you can reuse the GWT code, or you have to
reimplement the functionality in real Java so you can run your load
tester in a JVM.  Both approaches suck for different reasons.

The only tractable way to run JSNI that I can think of is to run in a
web browser.  Given that browsers generally limit the number of
concurrent connections to a given server, you need a lot of browser
instances to run a proper load test.  On the other hand,
reimplementing the client-side code in Java sucks because it'd be a
fair amount of work just to reach parity, and then you have to
maintain parity as the protocol changes.  The protocol has been fairly
stable, so that may not be a huge problem, but the protocol is
deliberately opaque because RPC is an area of active research.

> GWT is doing the
> serialization somewhere.  If the serialization isn't exposed in the
> API, could someone point me to some gwt source for some hints.  My
> source trail ends as soon as I enter the gwt client-side proxy.

Add the following arguments to the compiler's command line:

-gen "/some/path/somewhere"

After you do that, the compiler will generate code into
/some/path/somewhere, rather than in a throwaway location, and you can
inspect it.  I added that path to my project as a source location in
Eclipse, so I could, after refreshing the Package Explorer, step
through the generated code in the debugger.

Obviously none of this is impossible, but it's all hard enough that,
as far as I know, no one's done it yet.

Ian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to