I have a remote JSON Dataset with has an hourly refresh. When I view the data, I see the rows listed.
I’ve then created a layout using that dataset, and setting the Caching Update Interval to something higher then 60min.
When I preview the layout, I see the my dataset working nicely, however, when using it on a player I see no data presented, and the logs state:
getData: Failed to get data cache for widgetId 102, e = Cache not ready
No matter what values I seem to fill in for both the dataset or the caching settings on the layout, I keep getting this error.
Anyone know what the reason is I get this error ?
When we change data in the dataset so that the screen should update the call coming from the Player gets a 500 Response from the XDMS script.
"POST /xmds.php?v=7&method=getData HTTP/1.1" 500 597 "-" "Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 4.0.30319.42000)"
I disabled MEMCACHE at the docker compose file as well to see if that helps and it does not make a difference. We are on the same versions as @patrickfend
in my case the task “widget sync” was stuck. after a few attempts, the job ran and the cms now at least delivers data - sometimes. it seems like this is part of the cause.
i would say that it has to do with a combination between the scheduler of the widget sync task and the cache refresh of the dataset. if the cache of the dataset expires after 1 minute, but the widget sync only runs every 3 minutes, the XMDS service does not return any data =(
i have now set the widget sync to * * * * * * (every minute). so far the cache refresh of 1 minute for the datasets is working…but i still have to observe it for a while
what are your settings for the task and the dataset cache?
Is it still working for you?
i have the same problem, but the cache not ready keeps coming back…RSS and datasets don’t work in my layouts.
Is there perhaps a workaround?
I have the 4.0.11 CMS version in a Docker
Thanks for looping me in - yes it could be related.
This is the situation we’re attempting to solve with the linked issue above. The root of which came from a misunderstanding about what our caching library meant when it said it supported returning old data when the invalidation method was set to “OLD” (it doesn’t actually mean it returns old data). The fix we’re testing in the above issue intends to manually return old data in that situation.
For widgets which use a display specific cache (DataSet, Weather, etc) there was an other issue fixed in 4.0.12 which might also play into it. This related to the display requesting a cache without some of the parameters needed to select the right cache.
We’re actively looking into it to find a solution in any case.