Hi @nagarajan_subbaraj,
First I will talk about Pause/Resume
A pause followed by a resume should always make a “checkpoint” on the pause and then read the “checkpoint” on the resume.
I assume you are using I assume you are running 6.5 through 6.6.1 can you give me the exact version you are on ? Use the UI or the command line.
/opt/couchbase/bin/couchbase-server -v
Basically if you have any deployed function my example is named “test” as follows
function OnUpdate(doc, meta) {
log("Doc created/updated", meta.id);
}
with the source bucket fo the function “test” initially empty and we make a new doc with KEY doc_01_before_pause immediately you will see a new log message in the Eventing UI or in the file system /opt/couchbase/var/lib/couchbase/data/@eventing/test.log (not the UI is reverse sorted and combines nodes, while the file system is a subset of all vBuckets thus if you have more than one Eventing node you need to look at multiple files one per each node).
2021-03-02T10:30:16.211-08:00 [INFO] "Doc created/updated" "doc_01_before_pause"
Now let’s pause the function via the REST API
curl -XPOST http://Administrator:password@localhost:8096/api/v1/functions/test/pause
The “pause” action will create a checkpoint such that that Eventing knows exactly where it was paused.
Note while the function was paused I modified it in the UI (you don’t need to do this but I want to highlight how things work) so the modified function is now.
function OnUpdate(doc, meta) {
log("Modified my Function, Doc created/updated", meta.id);
}
Okay so it is time to resume the function we use the REST API call
curl -XPOST http://Administrator:password@localhost:8096/api/v1/functions/test/resume
Take a look at the log (UI or file system) there will be no new log messages since Eventing will only process the very next mutation after the “checkpoint” that pause took.
The last step prove the Eventing is still working here we make one more document in the source bucket (our second mutation) this second document will have KEY doc_02_after_resume
Again immediately you will see a new log message in the Eventing UI (or in the file system) remember the UI reverse sorts.
2021-03-02T10:46:44.147-08:00 [INFO] "Modified my Function, Doc created/updated" "doc_02_after_resume"
2021-03-02T10:30:16.211-08:00 [INFO] "Doc created/updated" "doc_01_before_pause"
This sequence is exactly how the pause/resume sequence should work if you follow my example above and see something different or a deviation please let me know ASAP.
Second I will talk about Deployment
If you want to deploy a function “From Now” via the REST API you can do this by altering the setting “dcp_stream_boundary” which can be either set to “everything” or “from_now” Note, the first call is just to ensure we have the function “test” in an undeployed state.
curl -XPOST http://Administrator:password@localhost:8096/api/v1/functions/test/undeploy
curl -XPOST -d '{"deployment_status":false,"processing_status":false,"dcp_stream_boundary":"from_now"}' http://Administrator:password@localhost:8096/api/v1/functions/test/settings
curl -XPOST http://Administrator:password@localhost:8096/api/v1/functions/test/deploy
At this point you should have no new mutations thus no new log messages at all regardless of 2 docs or 200M docs in the source bucket.
New UI setting/behaviour in the UI - version 6.6.2
You will have the ability via the UI to set the Deployment Feed Boundary as either “Everything” or “From now” as a “sticky” parameter that is remembered per function. You will no longer be able to change the value in the UI at deployment time in the confirmation pop-up, however in the UI (or REST API) you can still adjust the setting as needed.
This update is in response to the way some customers use Eventing in some use cases they always want to deploy form the beginning in other they only want to deploy form now.
I hope this helps
Jon Strabala