Hi Jeff, Thank you for your response. The size of the "message" debug output is 221KB. There are ~170 objects in a Heirarchical list with a max depth of ~5 child objects.
I also need to clearify my initial posting; the flash player is freezing AFTER the commit() and BEFORE my responder gets called by the AsyncToken. The pause I'm seeing doesn't seem indicative of serialization overhead. I do see an initial pause when I call commit. I put a breakpoint in my java DAO so I know when that gets called. It responds in a reasonable time (1-2 seconds). I can avoid the Freeze, if I call release() on the DataService. However this gives me the following error and of course the responder doesn't get called: Error: Unable to find the committed message batch with id 34A9FA18-58B7-7CDC-E2F5-587149047AD0 in the commit result handler. at mx.data::CommitResponder/result()[C:\dev\enterprise_gmc\frameworks\mx\data\CommitResponder.as:223] at mx.rpc::AsyncRequest/acknowledge()[C:\dev\enterprise_gmc\frameworks\mx\rpc\AsyncRequest.as:82] at NetConnectionChannel.as$37::NetConnectionMessageResponder/NetConnectionChannel.as$37:NetConnectionMessageResponder::resultHandler()[C:\dev\enterprise_gmc\frameworks\mx\messaging\channels\NetConnectionChannel.as:407] at mx.messaging::MessageResponder/result()[C:\dev\enterprise_gmc\frameworks\mx\messaging\MessageResponder.as:202] I essentially don't want fds to worry about updating the managed object on the front end, but I do want it to trigger the responder when the backend createItem is done and most importantly doing it without pegging the client's CPU. thanks, JB --- In flexcoders@yahoogroups.com, "Jeff Vroom" <[EMAIL PROTECTED]> wrote: > > I'm not sure how large "very large" is but it is certainly possible to > give the client too much work to cause this type of problem. The > createItem call will end up serializing the object which makes a > complete copy of it. If you have managed associations, there could be > additional work as it has to create the child objects as well. > > > > One way to get an idea of what is going on is to enable the debug > logging on the client side: <mx:TraceTarget/>, use the debug player, > and look in flashlog.txt in your home directory for the output. That > hopefully will make things even slower, but hopefully the trace log will > show some evidence of what is taking so long. If that does not show > anything, if you can get us a test case I'd be interested to take a look > ([EMAIL PROTECTED]). > > > > Jeff > > > > ________________________________ > > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of box110a > Sent: Tuesday, December 05, 2006 1:16 PM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] Flex 2: FDS Freezes Flash player before responders > get called > > > > I am calling dataService.createItem() a very large Object graph. After I > call commit, and my responder is called. the client flash player freezes > (browser stops responding, cpu utiliziaiton at 100%) for about 8-10 > seconds. I am releasing the itemReference from the createItem() call in > the responder. Does anybody have any idea how to debug this problem or > figure out what is causing it. > > thanks, > JB >