Page History

...

Unschedule a database quartz job

Note, you can look in the table grouper_qz_triggers and grouper_qz_job_details for more info

select * from grouper_loader_log where lower(job_name) like '%abc%' order by started_time desc;
select * from GROUPER_QZ_TRIGGERS where lower(trigger_name) like '%abc%';
select * from GROUPER_QZ_CRON_TRIGGERS where lower(trigger_name) like '%abc%';
select * from GROUPER_QZ_FIRED_TRIGGERS where lower(trigger_name) like '%abc%';
select * from grouper_qz_job_details gqjd where lower(GQJD.JOB_NAME ) like '%abc%';

If you get errors about a database quartz job, you can unschedule with (or whatever the trigger name is):

select trigger_name from GROUPER_QZ_TRIGGERS where lower(trigger_name) like '%abc%';
gsh 2% GrouperLoader.schedulerFactory().getScheduler().unscheduleJob(org.quartz.TriggerKey.triggerKey("triggerMessaging_MESSAGING_listener_messagingListener"))

...

Possible to do's

• add subject source to group attribute (or default at least) so it doesn't have to be a sql column if all are the same
• make specific blackout times (runtime via config file?)
• make jobs based on person trigger.  If there is a query that says when people change, then update that person's memberships in the groups that are dynamic based on that person-change-query
• make full refresh jobs for the incremental jobs (e.g. weekly)
• make an RMI server so that interactions can happen at runtime (to see status, stop/start jobs, etc).  Maybe this would happen from gsh
• try the name pattern after loader is done, and if the number of groups is less than the number of groups in this round of loader, set the job status to WARNING and add a descriptive message

...