When I first was building Media Mover, I put in a number of options that allowed an administrator to control how and when various configurations were run. For example, while Media Mover runs on cron by default, one could prevent this and use alternate means to run configurations. settings.php can also turn off specific configurations- very useful in a multi server environment where you want one box to serve the web content and different one to do the transcoding of files.
Â
It was not long before I started encountering issues- transcoding a 90mb file when the server is already under load is not exactly a good idea. So I wrote a little script that checked the current cpu load (with options for the 1, 5, and 15 minute samples) against an configurable setting to stop running when the box is under load.
Â
Then I built a helper module called Auto Run which ran a specified configuration on the creation or updating of a node. This worked great- for small files. The environment that I was working in used APC which really helps performance, but because of the short timeouts, conversions of files larger than 10mb kept dying.
Â
At this point, I realzied that the Auto Run module needed to check the file size before it tried to run a processing configuration on a file. It was at this moment that I realized that my approach was no longer sustainable.
Â
So I wrote a quick hook (hook_run_control($configuration, $name, $file)) which is fired at various points in the running of a configuration, which are identified by $name. This allows various modules to create their own stopping mechanisms. If any module that implements the hook and has a function for $name and returns false, the process is stopped.
Â
It's an obvious design pattern, but I over looked it when I was first writing as I kept adding onto the original code base without really stopping to consider the implications. I think the other aspect of it is that it allows for code compartmentalization which hopefully makes things easier in the long run.
Post new comment