Hi Tim, It's still conceivable for a circular reference (or at least massively repeated objects) to be at play here. Your response size is 165739 bytes *compressed* size - many identical objects could compress to something relatively small and their expansion could cause issues. Also with Hibernate you most likely won't see a lot of database traffic from repeated objects as subsequent fetch requests will hit the session's level 1 cache.
A quicker test could be to temporarily disable gzip encoding in your browser, for example here are instructions for FireFox: http://kb.mozillazine.org/Network.http.accept-encoding With gzip disabled, what size response does Jetty report? BTW - which browser are you using? Cheers, Chris. <http://kb.mozillazine.org/Network.http.accept-encoding> 2010/1/12 Tim Mattison <[email protected]> > That's what I thought originally but I can see that it's only pulling back > 165739 bytes from the RPC. When I don't return anything it turns out that > it runs quickly so it obviously must be related to that. > > I'm not using DTOs but where is it trying to fetch the data from if it's > not getting pulled back from the POST? I don't see any traffic to the > database server so it must be doing something weird locally (like a circular > reference as you suggested). Shouldn't it give up on circular references a > bit faster than that if that's the case? > > Tim > > On Tue, Jan 12, 2010 at 3:56 PM, Chris Lowe <[email protected]>wrote: > >> 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 <[email protected]> >> >>> 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]<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]<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.
