Seperate the MarkItemLost reactors from running with the rest of the daily triggers.

[Steve Callender]

In the action triggers, the MarkItemLost reactor can take an extra amount of time to finish due to the extra work it has to do and when running in conjunction with the rest of the triggers, can cause a timeout to occur causing none of the triggers to run.

I believe it is best to separate the running of this lost trigger out, so it will not interfere with the standard triggers if there is a heavy load.

[Steve Callender (stevecallender)]

Patch can be found at the following branch,

collab/Callender/seperate_auto_lost_trigger @ working/Evergreen.git

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=13d2d24cec8b98f50b929bebbeb4c008543568a6

[Mike Rylander (mrylander)]

I think there's a mismatch between the granularity being set on the definition in the DB and the new one being added to the cron job list. It looks like the DB should have a granularity of 'daily-lost'. If that's correct, I can make the change.

[Steve Callender (stevecallender)]

Mike,

Included in this patch should've been a DB update,

UPDATE action_trigger.event_definition set granularity='daily-lost'
where reactor='MarkItemLost' and granularity='daily';

Did I not do it right? I figured it should've been an update script
rather than a change to the master install scripts?

Steve

On 9/7/2011 5:10 PM, Mike Rylander wrote:
> I think there's a mismatch between the granularity being set on the
> definition in the DB and the new one being added to the cron job list.
> It looks like the DB should have a granularity of 'daily-lost'. If
> that's correct, I can make the change.
>

[Thomas Berezansky (tsbere)]

I believe you need to change both, so that fresh installs get the new value as well.

Maybe.

I can see arguments for *not* having the upgrade script, and just changing the default database load, to prevent existing cron setups from no longer running the MarkItemLost reactors at all due to not having the new granularity line installed at upgrade time.

[Ben Shum (bshum)]

Marking incomplete pending final conclusion for how to apply this change. Personally I'm with Thomas in not changing existing behavior without more warning to the end-users to add a new crontab entry for daily-lost. Maybe it's something we can cover through documentation as a release note entry?

[Galen Charlton (gmc)]

As the stock A/T definitions don't set any granularities other than print-on-demand anyway, I think we can dispense with any attempt at an automatic upgrade script.

A bit more work is required for the patch, IMO:

- get rid of the upgrade script
- add 'weekdays' and 'daily-lost' as options for granularity in the admin interface for A/T events (see bug 1205072 for an example of how to do it)
- write up release notes (which will mostly just be a recommendation for folks to take steps to separate out lost processing)