cacheAllData not working for 2016-04-11 nightly

[markok]

Hello,

We have a complex application that uses a lot of clientCustom-typed data sourced for fetching data. We updated our application from LGPL 5.0p-2016-01-07 nightly to latest 2016-04-11 nightly and suddenly our data sources configured to setCacheAllData(true) stopped caching.

We are getting tons of requests to our server. It seems that for some reason, setAutoCacheAllData(true) and/or setCacheAllData(true) and setCacheMaxAge(...) calls have no effect. All requests go to the server.

We ran some diffs on the code and DataSource.js has a change on line 22170 as

...
            this.addMethods({
                _isServerRequest : function (dsRequest) {
                    
                    return this.dataProtocol == "clientCustom" ||
                        dsRequest.cachingAllData ||
                        (this.cacheAcrossOperationIds && 
                            (dsRequest.operationType && dsRequest.operationType != "fetch")) ||
                        (this.cacheAcrossOperationIds === false && 
                            this.cacheAllOperationId != 
                                (dsRequest.operationId || dsRequest.operation)
                        )
                    ;
                },
...

.. which seems to check against the clientCustom typed dataprotocol. Would this cause for caching to fail and is this intentional ? Any workarounds ?

Thanks,
Marko

[markok]

We made additional testing with this by going through nightlies trying to find the nightly where the problem starts to occur.

The 5.0p 'v10.0p_2016-01-21/LGPL' still works normally and with the nightly 'v10.0p_2016-01-31/LGPL' these problems start to occur. In addition to the caching not working anymore, we are getting these warnings to the logging console

...
10:31:27.616:TMR7:INFO:ResultSet:isc_ResultSet_19 (dataSource: Milestone, created by: isc_PickListMenu_15):server returned out-of-sequence response for fetch remote data request  - delaying processing: last processed:1, returned:1
...

We don't know if the warnings are just a symptom of something else or the cause.

Does this help at all ?

As a background, we've had this CLIENTCUSTOM based server protocol in place from the days of SmartGWT 2.x and it has worked since. This is real blocker for us as it breaks the upgrade path for any future versions.

Thanks in advance,
Marko

[Isomorphic]

The change you identified in your first post indeed broke this combination of settings. It was implemented as part of a bugfix for a related use case. We're revisiting it now. The warnings are almost certainly just a consequence of the original break and not a separate problem.

[Isomorphic]

We've made changes to address this, and retested the issue that prompted the original regressive change.

You didn't show sample code, so we can't test your specific queries - please restest with a build dated April 16 or later and let us know if you still see issues, probably with sample code that shows the problem.

[markok]

Will do. A big thanks for your fast response on this issue.

[markok]

To report back, I'm testing with NIGHTLY-2016-04-19 of 5.0p / LGPL and we are still seeing problems. The caching does not work.

Was the fix merged to 5.0p/LGPL ? I'm still seeing the

return this.dataProtocol == "clientCustom" ||

.. line in DataSource.js present.

[Isomorphic]

The fix hadn't been ported that far back - it should be there for tomorrow's 5.0 builds.

[markok]

This is now fixed and verified to be working up to 5.0p nightly 2016-05-07. Thanks!