I changed my debug level from "Info" to "Debug" and got lots of additional output but nothing that looked like it was the culprit. My application runs like this:
1) onModuleLoad is called, builds the UI, and fires off a GWT-RPC call
2) The server receives the GWT-RPC call, connects to a Hibernate database,
pulls some data (~150K) and sends it to the client
3) The client receives the response and populates a FlexTable with the data
Between 2 and 3 is where the storm of traffic occurs. With the new debug
level I don't really get much more insight since I see that Jetty has sent
the response to the browser and that's it. I have breakpoints set on my
GWT-RPC callback's onFailure and onSuccess method and it doesn't get to
either of those branches until minutes later. Is there somewhere else I can
look or something else I can try?
The last message in the log before the storm:
200 - POST /app/service (127.0.0.1) 165739 bytes
Request headers
Host: localhost:8888
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: no-cache
Referer: http://localhost:8888/app/hosted.html?app
X-GWT-Permutation: HostedMode
X-GWT-Module-Base: http://localhost:8888/app/
Content-Type: text/x-gwt-rpc; charset=utf-8
Content-Length: 175
Pragma: no-cache
Response headers
Content-Encoding: gzip
Content-Length: 165739
Content-Type: application/json; charset=utf-8
Content-Disposition: attachment
The first message after it hits onSuccess and then keeps going at a normal
speed:
304 - GET /app/gwt/standard/images/hborder.png (127.0.0.1)
Request headers
Host: localhost:8888
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost:8888/app/gwt/standard/standard.css
If-Modified-Since: Tue, 03 Nov 2009 15:44:06 GMT
Cache-Control: max-age=0
Response headers
Any help would be great.
Tim
On Tue, Jan 12, 2010 at 3:04 PM, Chris Ramsdale <[email protected]>wrote:
> Although this smells of a network configuration issue, one suggestion you
> could try is to set the log level to Debug or lower.
>
> Debug->Debug Configurations->GWT->Log level.
>
> Try that, and let us know if anything suspect is output.
>
> - Chris
>
> On Mon, Jan 11, 2010 at 11:56 AM, timmattison <[email protected]>wrote:
>
>> I just started using OOPHM on my Mac (10.6.2) and it is very, very
>> slow. I've tried all of the recommendations about changing the URL to
>> include only "localhost" or "127.0.0.1" but I still have to wait
>> nearly three minutes for my application to start.
>>
>> The program I'm writing is currently very small and only consists of
>> less than 200 lines of code. It does import a JAR that contains
>> definitions of a lot of objects and has some dependencies (Gilead,
>> Hibernate, GXT) for the server side components but right now I'm just
>> using basic GWT components. Does the size of the dependencies and
>> included JARs matter?
>>
>> I ask because I notice that as soon as I start the application the
>> traffic on port 9997 to and from my loopback interface is pegged at
>> 1.5MB/sec in each direction for the entire three minutes the
>> application is starting up. I stepped through my code with a debugger
>> and the client side code gets set up, runs, then there's a three
>> minute pause where all of this data goes back and forth, and then the
>> server-side code runs. The client and server side code takes less
>> than 1 second to finish so I don't think it's a bug in my code.
>>
>> I tried to capture the traffic in Wireshark to figure out what is
>> getting sent but it looks like all of the packets are very small (~56
>> bytes) and trying to capture the whole session causes Wireshark to
>> crash.
>>
>> Is anyone else seeing this loopback traffic problem? I assumed maybe
>> the debugger is communicating my dependencies to the OOPHM plugin but
>> my dependencies are nowhere near this large.
>>
>> What other information can I provide to help this get debugged?
>>
>> Thanks,
>> Tim Mattison
>>
>> --
>> 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]<google-web-toolkit%[email protected]>
>> .
>> For more options, visit this group at
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>
>>
>>
>>
>
> --
> 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]<google-web-toolkit%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>
-- 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.
