Jon Strabala added a comment - 22/Jul/20 10:44 AM - edited   Sriram Melkote Proposed DOC pull request  https://github.com/couchbase/docs-server/pull/1431 (new section to  https://github.com/couchbase/docs-server/edit/release/6.5/modules/eventing/pages/eventing-timers.adoc ) should we also reference  MB-28734 (fix) and MB-39301 (fix) ? Limitations In the 5.5.x, 6.0.x and 6.5.x releases   Eventing timers once created cannot be overwritten by using the same reference. In addition, a function that is invoked by a timer callback cannot reliably create a fresh timer (a work around can be done via a second cooperative Function).   In the 6.5.X releases Creating timers in the future (as in one hour+) in an otherwise idle system can result in a growing number of metadata bucket operations which can eventually block mutations for a given Eventing function. In 6.5.X a user space work around can be accomplished via a second cooperative Function.  The severity is governed by: The number of vBuckets holding an active timer. Therefore if there are only a few timers in the future the issue may not be noticeable or materialize. Whether an Eventing timer has fired recently on a vBucket (which clears the issue for the given vBucket on a per function basis). Therefore systems with lots of near term timer activity will not experience this issue even if timers are scheduled far into the future.   All of these limitations are removed in release 6.6.0 Eventing timers can be cancelled using cancelTimer() function, or by creating a new timer with the same reference as an existing timer. Recurring timers are fully supported, i.e. a function that is invoked by a timer callback can reliably create fresh timers. Timers can be created days/weeks/years in the future with no adverse performance impact on an otherwise idle Eventing system.

Amarantha Kulkarni (Inactive) added a comment - 12/Aug/20 5:07 AM https://docs-staging.couchbase.com/server/6.6/release-notes/relnotes.html