docs-cb4/content/eventing/eventing-Terminologies.dita at 5f47862fd7801861405c13a68f5300edf5bf098e · couchbase/docs-cb4 · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic id="eventing_operations">
  <title> Terminology</title>
  <shortdesc> While using Functions, the following terminologies are used: </shortdesc>
  <body>
    <section id="section_hny_sz4_m2b"><title>Functions</title>Functions offers a computing paradigm
      using which developers can handle data changes. Functions are either <b>OnUpdate</b> or
        <b>OnDelete</b>. Resources are managed at or above a Function level, and the containing
      Function scopes the state of all handlers.</section>
    <section id="section_k12_5z4_m2b">
      <title>Handler</title>
      <p>A stateless, short-running code-fragment that reacts to a specified event. One or more
        handlers together constitute a Function. A handler must execute from start to finish, before
        a specified timeout-duration. Currently, <b>OnUpdate</b> and <b>OnDelete</b> are the two
        supported handlers. Couchbase Functions support multiple <b>OnUpdate</b>/<b>OnDelete</b>
        handlers during the Function definition process. </p>
      <note>
        <p dir="ltr">In the Couchbase Server 5.5 release, the handler code size is limited to 128KB.
        </p>
      </note>
    </section>
    <section id="section_tyn_wz4_m2b">
      <title>Statelessness</title>
      <p>The persistent state of a Function is captured by entities listed below, while any state
        that appears on the execution stack is ephemeral. </p>
      <p>
        <ul id="ul_dtx_11p_m2b">
          <li>The metadata bucket (which will eventually be a system collection). </li>
          <li>The document being observed and its Extended Attributes. </li>
        </ul>
      </p>
    </section>
    <section id="section_k5h_c1p_m2b">
      <title>Buckets</title>
      <p> Every Function definition needs two distinct buckets: source bucket and metadata bucket. </p>
      <p>The Functions use a source bucket to listen to data changes. The Function handler code
        polls the source bucket for data mutations. Multiple Functions can use the same source
        bucket. </p>
      <p>Metadata bucket stores internal artifacts and checkpoint information. The metadata bucket
        provides better restartability semantics when the eventing nodes is offline. Ensure that
        your Function handler code does not write any data to this bucket.  </p>
      <p>The Functions can in turn trigger data mutations, to avoid a cyclic generation of events,
        ensure that you carefully consider options when you select the source and destination
        buckets. When you are using a series of handlers, ensure that: </p>
      <p>
        <ul id="ul_gpw_sdl_n2b">
          <li>The source bucket can be either Couchbase or Ephemeral bucket. However, memcached
            buckets are not supported. </li>
          <li>Metadata bucket is used by the Eventing Service to store some critical checkpoint
            information. Avoid writing to the metadata bucket or flushing it. It is recommended that
            a separate bucket be kept destined as a metadata bucket. </li>
          <li>A read operation from the source bucket is allowed but operations such as delete, set
            and update are not supported. </li>
          <li>The destination buckets to which event handlers perform a write operation, do not have
            other event handlers configured to listen and track data mutations. </li>
        </ul>
      </p>
    </section>
    <section id="section_l1j_21p_m2b">
      <title>Workers</title>
      <p> Workers can be defined as an execution unit that is assigned a group of vBuckets. The
        worker units are used mostly during Function execution. </p>
    </section>
    <section id="section_mzd_l1p_m2b">
      <title>Bindings</title>
      <p>Bindings are constructs that allow the separating of environment-specific variables from
        the handler source code such as bucket-names, external endpoint URLs, and credentials.
        Bindings allow Functions to be developed without source-code changes while working on
        different workflows. Using bindings, you can port source code from different environments
        such as Test-to-Test, Test-to-Production, or Production-to-Production environments without
        making code changes. </p>
      <p>During Function definition when you are creating a bindings name-value pair, for a source
        bucket, ensure that only read operation is performed in the Function handler code. </p>
    </section>
    <section id="section_zjr_m1p_m2b">
      <title>Function Settings</title>
      <p> The log levels, script timeout, and workers allocation are additional options available
        during the Function definition process. </p>
      <p>
        <ul id="ul_nzw_41p_m2b">
          <li><b>Log Levels</b>: Use log levels to determine the granularity of log messages. </li>
          <li><b>Script Timeout</b>: Script Timeout provides a timeout option to terminate a
            non-responsive Function. </li>
          <li><b>Workers</b>: Workers allocate the number of worker threads for a specific Function.
            <p/>For a defined Function, Couchbase Server limits the maximum number of workers to 10.
            This upper limit is configured for system optimization purposes. In the Function
            definition, if the number of workers exceeds a set threshold, then the system
            automatically generates a warning message. However, this warning message does not
            prevent deployment of the Function.</li>
        </ul>
      </p>
    </section>
    <section id="section_kdm_s1p_m2b">
      <title>Deploy</title>
      <p>The deploy operation activates a Function. Multiple Functions can be deployed in a cluster.
        Couchbase server performs source validations before deploying a Function, and only valid
        Functions get deployed. The deploy operation transpiles the code and creates the executable
        v8 artifacts. The source code of a deployed Function cannot be edited. The Function must be
        in a deployed status to process events. Once you deploy a Function, depending on the Feed
        Boundary conditions, the Function execution starts processing the data mutations. Deployment
        of a Function triggers actions such as creating of necessary metadata, initiating worker
        processes, calculating initial partitions, and creating checkpoints of processed stream
        data. To edit a deployed Function, you must first un-deploy the Function. </p>
    </section>
    <section id="section_pdn_t1p_m2b">
      <title>Feed Boundary</title>
      <p> Feed Boundary is a time milestone used during a Function configuration. Using the Feed
        Boundary option, you can either invoke a Function on all the data present in the cluster or
        choose to invoke a Function during future instances of data mutation, post Function
        deployment. </p>
    </section>
    <section id="section_ngz_51p_m2b">
      <title>Undeploy</title>
      <p>An undeploy operation causes the Function to stop processing events. All allocated
        worker-processes get terminated, and any runtime resources acquired by the Function gets
        released. Functions in an undeployed state allow editing of the Function handler code. After
        a successful undeploy operation, system does not retain the previous state. During
        redeployment, the Eventing service cannot resume from a prior state before undeployment. An
        undeployed Function retains the memory of its prior deployment, if necessary. Newly created
        handlers start in an undeployed state.</p>
    </section>
    <section id="section_wfw_w1p_m2b"><title>Delete</title> When a Function gets deleted, the source
      code implementing the Function, all processing checkpoints, and other artifacts in the
      metadata provider are purged. Before deleting, make sure you have undeployed the Function.
    </section>
  </body>
</topic>