Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Code Block
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"))

Performance Settings

These are the default settings:

Code Block
# if should use threads in the loader for add/remove member
# {valueType: "boolean", required: true}

# number of threads to use for each group job (not shared among jobs)
# {valueType: "integer", required: true}

# if should use threads in the loader for each group in a group of groups
# {valueType: "boolean", required: true}

# number of threads to use for each list of groups job (not shared among jobs)
# {valueType: "integer", required: true}

So for a simple job (SQL_SIMPLE, LDAP_SIMPLE), you can have up to 10 threads.  However for a single groupList job (SQL_GROUP_LIST, LDAP_GROUP_LIST, LDAP_GROUPS_FROM_ATTRIBUTES), you can have up to 200 threads since each of the 20 group threads can have 10 membership threads.

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