No announcement yet.
  • Filter
  • Time
Clear All
new posts

  • Robustness with cacheAllData & cacheMaxAge


    We have some data sources which we've configured to cache the data for 30 seconds to avoid too many server roundtrips. The data sources are basically configured as


    We've aiming here for 30 seconds of caching in the client and periodical refresh of the data from the server and this works. Occasionally, quite rarely - but sometimes, some editors in the grids of our application get stuck as "Loading data ..." with these data sources and they seem not to be able to recover from the situation. We have trouble repeating the issue and we suspect that it has something to do with some network errors or such. For example, it can sometimes be seen when a user changes a wifi network (or something similar) and the browser's network has a hiccup of some kind.

    My question is that does the protocol which fires the update for an expired cache (in our case every 30 seconds or longer) have a robust timeout handling or something else that should prevent this problem? My experience is that the controls relying on these data sources get stuck and it at least seems that the editors don't automatically recover when the initial cachealldata-fetch has failed. Also, this never happens for us with any control which has a data source defined to not cache the data for some seconds.


  • #2
    Many many things could be going wrong. We need client and, if relevant, server diagnostics for one of the failures. See the FAQ for the other rqeuired information you've also omitted.


    • #3
      We are using SmartGWT 6.0 LGPL nightly build 2017-04-09. We have trouble repeating the issue so providing a client is close to impossible. Also, server diagnostics are probably no use as there are numerous different scenarios where this could happen (an error status sent by the server, socket opened by no response, socket closed, timeout, network change, ...). What I am trying to say the server diagnostics are irrelevant in a sense, that the client should, in any case, have a logic in place to handle failed requests.

      A simple question: What does the auto loading component (a component configured to cache all data) do if the request for cache data fails?


      • #4
        There are lots of different kinds of failure - timeouts, failure to return any data, error responses, garbled responses, etc. The framework code looks to handle these failures correctly, but with any of these bad responses, callbacks or overrides from your code could crash even if the framework code is handling the error correctly. So, sorry, but there is no shortcut to either gathering some kind of diagnostic about the crash that's actually happening, or trying to put together a test case showing a specific issue with handling error responses.