Trying to split deserialization process after RPC call

[Damien Picard]

Hi,

In a few words, I've got a problem with big object deserialization after an RPC call.
On Internet Explorer, the browser ask me to interrupt the script because the deserialization process is too long.

In fact, my RPC service returns a deep recursive tree, and some other data, where the Item is called Option :

The generated FieldSerializer looks like :

public static void deserialize(com.google.gwt.user.client.rpc.SerializationStreamReader streamReader, Option instance) throws com.google.gwt.user.client.rpc.SerializationException{
    //The childs of this Option node, defining the tree
    setChildren(instance, (java.util.List) streamReader.readObject());
    //Some other atomic data
    (...)
 
  }

In my mind, the invocation of setChildren() involves that the childs Options are deserialized too. And, because of my tree is too deep, this deserialization process leeds to have a "Would you like to interrupt the script ?" in IE6/7.

I think I could resolve this problem by adding a deferred command in this process :

public static void deserialize(com.google.gwt.user.client.rpc.SerializationStreamReader streamReader, Option instance) throws com.google.gwt.user.client.rpc.SerializationException{
    //The childs of this Option node, defining the tree
    Command c = new Command(){
        public void execute(){
           setChildren(instance, (java.util.List) streamReader.readObject());
        }
    }
    DeferredCommand.addPause();
    DeferredCommand.addCommand(c);
    //Some other atomic data
    (...)
 
  }

But, to do that, I have to modify the generator of this serializer, and i've not found where I can do that. So my questions are :

• Is it a good idea ?
• How can I modify /implement my own serializer generator for this tree ?
  

P.S. : Furthermore, I will have to deal with asynchronism because of my deserialize method will returns before my tree will be totaly deserialized ; but I will work on this in a second step.

Thank you.

--
Damien Picard
Axeiya Services : http://axeiya.com/
gwt-ckeditor : http://code.google.com/p/gwt-ckeditor/
Mon livre sur GWT : http://axeiya.com/index.php/ouvrage-gwt.html

[George Georgovassilis]

Hello Damien,

That is an uggly problem. Unfortunately I'm not too fluent on
generators, but if you are willing to consider some alternatives there
might be some:

- DeRPC. It's not exactly over-documented, so you might have to do
some searching but it's supposedly a lot faster than RPC while just as
easy to use.

- JSON

- XML. I mention it here because it is designed for hierarchical
structures like trees, and you can incrementally parse it

- Return a string that contains some representation of your data and
parse it on your own

On Dec 19, 9:43 am, Damien Picard <picard.dam...@gmail.com> wrote:
> Hi,
>
> In a few words, I've got a problem with big object deserialization after an
> RPC call.
> On Internet Explorer, the browser ask me to interrupt the script because the
> deserialization process is too long.
>
> In fact, my RPC service returns a deep recursive tree, and some other data,
> where the Item is called Option :
>
> The generated FieldSerializer looks like :
>
> public static void
> deserialize(com.google.gwt.user.client.rpc.SerializationStreamReader
> streamReader, Option instance) throws
> com.google.gwt.user.client.rpc.SerializationException{
>     //The childs of this Option node, defining the tree

>   *  setChildren(instance, (java.util.List) streamReader.readObject());*
>  *   //Some other atomic data
>     (...)*

>
>   }
>
> In my mind, the invocation of setChildren() involves that the childs Options
> are deserialized too. And, because of my tree is too deep, this
> deserialization process leeds to have a "Would you like to interrupt the
> script ?" in IE6/7.
>
> I think I could resolve this problem by adding a deferred command in this
> process :
>
> public static void
> deserialize(com.google.gwt.user.client.rpc.SerializationStreamReader
> streamReader, Option instance) throws
> com.google.gwt.user.client.rpc.SerializationException{
>     //The childs of this Option node, defining the tree
>     Command c = new Command(){

>   *      public void execute(){
>            setChildren(instance, (java.util.List)
> streamReader.readObject());*
>         }
>     }
>     DeferredCommand.addPause();
>     DeferredCommand.addCommand(c);
>  *   //Some other atomic data
>     (...)*

>
>   }
>
> But, to do that, I have to modify the generator of this serializer, and i've
> not found where I can do that. So my questions are :
>

>    - Is it a good idea ?
>    - How can I modify /implement my own serializer generator for this tree ?

[David Chandler]

Following up on George's post, here's the DeRPC doc. You can find a
little additional info by searching for "DeRPC" on the public issue
tracker. DeRPC was created to help with large object graph
serialization; however, DeRPC (NOT GWT-RPC) will likely be deprecated
eventually in favor of RequestFactory.

http://code.google.com/webtoolkit/doc/latest/DevGuideServerCommunication.html#DevGuideDeRPC
http://code.google.com/p/google-web-toolkit/issues/list

/dmc

> --
> 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-we...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-tool...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>

--
David Chandler
Developer Programs Engineer, Google Web Toolkit
http://googlewebtoolkit.blogspot.com/

[Damien Picard]

Thank you for your advices.

I think I will linearize the tree as a List by replacing the strong reference link between an Option and its childs to a String meaning the id (the id is an attribute) of the child options.

Then, I will serialize the option list to a json String with flexjson and send it to the client over GWT-RPC.

On the client, I think that the json String deserialization will be done quickly ; I've seen on StreamReader source code that the String deserialisation does not lead to a lot of compute time because the HTTP response is String itself. Then, I will deserialize this json String with the eval() method, and I will try to map it to my Option type with a JavaScript Overlay Types.

And, if there is a need to split deserialization into multiple deferred command, I will split my json String into multiple json string before evaluating this with eval(), and do the eval() on each sub-sequence json string in a deferred command. Even if this split is not simple...

What do you think about this solution ?

2010/12/20 David Chandler <drfib...@google.com>

[A. Stevko]

Wow Damien - I like it. Thanks for the tips. 

-- A. Stevko

===========

"If everything seems under control, you're just not going fast enough." M. Andretti

[Damien Picard]

I've carried out this solution except that I haven't used GWT-RPC ; I have used a RequestBuilder and a standard servlet to serve the JSON string.

To serialize my objects in JSON, I have defined an interface for my DTO :

interface ExtendedOption {
    String getId();
    ...
}

its server-side version :

class ExtendedOptionImpl implements ExtendedOption{
   
    private String id;

    public String getId(){ return id; }
}

and its client-side version with a JSOT :

class ExtendedOptionJSOT extends JavaScriptObject implements ExtendedOption {

    public static native ExtendedOptionJSOT create(String jsonExtendedOption) /*-{
        eval("var obj = " + jsonExtendedOption);
        return obj;
    }-*/;

    public native String getId() /*-{
        return this.id;
    }-*/;
}

To finish, I serialize ExtendedOptionImpl with flexjson on the server, and I deserialize it with the create method client-side.

The performances are really better : I've not measured the gain, but this is around 10x faster than GWT-RPC in my case.

Thank you for your help.

2010/12/21 A. Stevko <andy....@gmail.com>