Tim, Are you filtering your Hibernate objects or translating them to DTOs (to remove dynamic proxies etc) before serialising them?
If the answer is no to the above, then you might be falling foul to circular references or Hibernate fetching more data than you expect. As an experiment, is it possible to try hardcoding some of your objects with a minimal data set and see how your app performs? Cheers, Chris. 2010/1/12 Tim Mattison <timmatti...@gmail.com> > 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 <cramsd...@google.com>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 <timmatti...@gmail.com>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 google-web-toolkit@googlegroups.com >>> . >>> To unsubscribe from this group, send email to >>> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> >>> . >>> 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 google-web-tool...@googlegroups.com. >> To unsubscribe from this group, send email to >> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> >> . >> 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 google-web-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > . > 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 google-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
