SmartGWT 14.1 Serialization Speed Slow

aderosso replied

11 Jun 2025, 05:23
This is fixed in the 14.1-p20250611 built, thank you!
Leave a comment:

aderosso replied

2 Jun 2025, 09:22

Yes, this is an update operation.

Here's an example of the request:

Code:

{
    dataSource:"OpeningSQL",
    operationType:"update",
    componentId:"titanOpeningListGridId",
    data:{
        openingId:2294087,
        width:153600,
        height:307200,
        jambDepth:19200,
        mark:"104"
    },
    textMatchStyle:"exact",
    willHandleError:true,
    showPrompt:false,
    oldValues:{... ommitted for brevity ...},
    requestId:"OpeningSQL$62736",
    internalClientContext:{
        saveCallback:{
        },
        newValues:{
            openingId:2294087,
            width:153600,
            height:307200,
            jambDepth:19200,
            mark:"104"
        },
        editInfo:{
            editValuesID:"_1",
            rowNum:4,
            colNum:3,
            values:Obj,
            oldValues:Obj,
            editCompletionEvent:"enter"
        }
    },
    fallbackToEval:false,
    lastClientEventThreadCode:"KPR4",
    bypassCache:true,
    dataProtocol:"getParams"
}

There isn't a queue or anything with multiple updates sent to the server, but we do have our own binding for this operation that does a lot of other stuff besides just updating the table directly with the new values being sent.

We're not expecting the openingDoorSet or questionOpeningSet fields to be filled in automatically, that's why they've been marked as customSQL=true. After all of the updates happen on the server, we re-fetch by primary key and our fetch operation fills in those custom fields. There aren't many values in those fields either, openingDoorSet would have a maximum of 4 records, but usually just 1. The field questionOpeningSet could have 0 or many records, but for all of this testing it's zero.

Leave a comment:

Isomorphic replied

1 Jun 2025, 04:33
Hmm, if you aren't getting any extra data back, our initial theory seems less likely. Could you please describe the request/response in a bit more detail? Two of the log entries say "Executing cache sync query", so presumably this is an update operation? Just an update on the "OpeningSQL" dataSource, or a queue that also includes updates to the other two dataSources? Do you expect the cache sync query for an "OpeningSQL" update (or a regular fetch on that dataSource) to return values for the "openingDoorSet" and "questionOpeningSet" fields? If so, how are they populated, and how many entries would you expect in a typical fetch ?
Leave a comment:
aderosso replied

30 May 2025, 08:55
I'm not seeing any additional data coming back in the response that I wouldn't expect. I'm also seeing all of the correct SQL statements that I would expect, nothing fetching lots of additional data.

I sent the requested files via email.
Leave a comment:
Isomorphic replied

30 May 2025, 02:34
Also, could you please share the .ds.xml files for "OpeningDoorSQL" and "QuestionOpeningSQL", and the generated SQL? If you don't want to share this information on the public forums, please email to support@isomorphic.com
Leave a comment:
Isomorphic replied

29 May 2025, 19:31
Almost certain we know what this is - it's the new Relation Fields feature, probably misfiring in this instance.

Just to clarify: are you seeing massively larger actual responses? Because what we're guessing is that you have a DMI that is meant to do something similar to the current Relation Fields feature, that is, return a few subobjects from another DataSource.

But what's likely happening is that the Relation Fields feature is also trying to populate that field for you, and probably succeeding. Except it's either sending back lots of additional objects that your code doesn't, or it's sending them back with all the fields (including maybe some expensively large ones).

Can you check on the responses and let us know? We'll check on the possibilities internally as well.
Leave a comment:

aderosso replied

29 May 2025, 11:42

I think this has to do with fields marked as multiple="true" that have a type defined as another data source.

Here's the datasource in question:

Code:

<DataSource ID="OpeningSQL"
            serverType="sql"
            tableName="opening"
            beanClassName="bean.Opening"
            dropExtraFields="false"
            xmlns:fmt="WEB-INF/">
    <fields>
        <field name="openingId" nativeName="opening_id" type="sequence" primaryKey="true" hidden="true"/>

...

        <field name="openingDoorSet" type="OpeningDoorSQL" multiple="true" customSQL="true"/>
        <field name="questionOpeningSet" type="QuestionOpeningSQL" multiple="true" customSQL="true"/>
    </fields>
</DataSource>

Simply removing the type dramatically improves the serialization time:

Code:

        <field name="openingDoorSet" multiple="true" customSQL="true"/>
        <field name="questionOpeningSet" multiple="true" customSQL="true"/>