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 [email protected], "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: [email protected] [mailto:[EMAIL PROTECTED] On
> Behalf Of box110a
> Sent: Tuesday, December 05, 2006 1:16 PM
> To: [email protected]
> 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
>
