On Sunday 04 November 2007 18:31, David Boyes wrote: > > 1. Allow Duplicate Jobs = Yes | No | Higher (Yes) > > Looks OK. One question: if a lower level job is running, and a higher > level job attempts to start, does this imply that the lower level job is > cancelled, and the higher level one is run instead? I think this is > desirable behavior if possible (or maybe it might require an additional > option of Supercede for this directive to enable this behavior).
I hadn't planned to cancel the lower priority job, but I had thought about the possibility. However, now that you mention it, I think we need some keyword to do this. Any suggestions? -- CancelLower, HigherWithCancel ? By the way, if a lower priority job is scheduled, but not running, I was planning to cancel it. A new keyword would certainly clarify what should happen. > > > 2. Duplicate Job Interval = <time-interval> (0) > > The semantics look fine, but a usability suggestion: > > Since you're really setting a proximity guard interval, it might be > easier to understand for the end user if you used Duplicate Job > Proximity rather than Interval. That would give the implication of "no > closer than" that I think you want, and it might translate better. Yes, I was thinking of calling it Duplicate Job Delay, but that was confusing. I think "Duplicate Job Proximity" will be the most clear. Thanks. Another point is that I could do a lot of this in the scheduler -- i.e. just not run jobs if one was already running, but I think I will actually "start" the job, print a message, then cancel it if it is of equal or lower priority (i.e. not supposed to run). That way, there will be some record. We might even want to invent a new message class (for example: AutoCancelled) so that the job output from such jobs could be sent elsewhere (i.e. down the bit bucket if one wants). > > > PS: I think the default for Allow Duplicate Jobs should be Higher, but > > that > > would change current behavior ... > > I agree with you. It's dumb to do an incremental followed immediately by > a full backup if they're going to dump the same data in roughly the same > timeframe. Yes, but I always hesitate to make non-compatible changes ... Thanks for the ideas, Kern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
