The purpose is to improve sustainability of 389-ds. I think it could be helpful to have various counters recorded in order to detect server spikes/drop/response_time...
Each counters being reset at each log.

• Nb add/del/mod/srch/ext (other than repl)/repl_op/bind...
• total duration of add/del/mod/srch
• Nb of connections established
• length of the work queue
  ....

In addition, frequency of the log should be tunable up to one per second
Why using nunc-stans event rather than the existing mechanism to record timely repeatable event ?

All the existing mechanisms (housekeeping etc) will become NS timer events soon @tbordaz so we can give a predictable number of threads in process-limited environments. Spawning our own threads around the place may hit a process/thread limit in some cases, but with NS we have a bounded number that's detected properly, so we can just submit async-jobs :)

okay. note that it will slightly change our current slapi_eq_* internal behavior. Currently it does not create a thread, all schedule jobs are currently serialized.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2485

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.