Note that if you make changes to this file, you should also edit /opt/kaltura/app/configurations/cron/dwh.template, otherwise, your changes will be overridden whenever you run the kaltura-*config.sh scripts.
I figured that would be the implementation steps. However, I was wondering if there was any known side effects of doing so. That is, was this process designed to be only run once per day for a reason?
I wouldn’t think so, but I thought it would be worth asking.
It certainly wasn’t designed to be real time. The intervals with which you can get away with greatly vary depending on the amount of data you have to process. If you invoke these scripts at too small intervals, you may reach a situation in which the last invoked process still hasn’t exited. There’s a locking mechanism [see kalturadw_ds.locks] that’s meant to prevent additional instances of the same job from running but all the same, it would mean that you’ll have to wait for the current proc to finish. Also, the order in which these run is important.
Thanks @jess. This makes sense. Looking at the timestamps in the log for this specific script, it runs in about 8 seconds now. I certainly don’t need real time. I don’t expect my little instance to get so much traffic that I would need to bump it out further.
I haven’t studied the whole dwh process end to end yet, but I’m wondering if there are other processes that need to run before this would run in order to see updated plays and “viewed at” dates.
In other words, what data does the dwh_plays_vews_sync script use that is also updated by another dwh process that has it’s own schedule?