...
| Setting | Description | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Bucket Configuration | |||||||||||
Bucket Name | Enter the bucket that you want to access in Couchbase in this field. | ||||||||||
| Bucket User | Enter the user who has access rights to the bucket. | ||||||||||
User Password | Enter the password for the user who has access to the bucket. If you want to set a parameter, select the Parameterized checkbox and enter the parameter name using ${} syntax, see Profiles for more information on how parameterization works (in this mode the regular User Password field is disabled). | ||||||||||
Admin User | Enter the user with admin credentials to manage the Couchbase cluster. | ||||||||||
| Admin Password | Enter the password for the admin user. | ||||||||||
| Parameterized | When enabled, here you may enter a parameterized bucket configuration. | ||||||||||
| Cluster Connectivity | |||||||||||
Operation Timeout (ms) | Enter the number of milliseconds after which you want Couchbase "CRUD" operations, that is, create, read, update, and delete, to timeout. Setting a lower value than the default 1000 ms may have a positive impact on throughput performance. However, if the value is set too low, indicated by a large number of operation timeouts errors in the EC logs, a lower throughput can be expected. As mentioned, this value is used for timing out CRUD operations in Couchbase. This means that the system sends a request towards Couchbase and if an answer is not returned in time, the operation fails, and is the system is no longer waiting for an answer. | ||||||||||
Retry Interval Time (ms) | Enter the time interval, in milliseconds, that you want to wait before trying to read the cluster configuration again after a failed attempt. In other words, in case a request sent to Couchbase returns an unsuccessful answer, the number specified here is the time that waits the system waits before retrying the same request. | ||||||||||
Max Number Of Retries | Enter the maximum number of retries. This This is the number of retries does the system does before treating the Couchbase operation as failed. | ||||||||||
| Enable Security | Select this checkbox to connect to Couchbase cluster with SSL. If you want to set a parameter, select the Parameterized checkbox and enter the parameter name using ${} syntax, see Profiles for more information on how parameterization works (in this mode the regular Enable Security checkbox is disabled). The parameter needs to be set as true or false. | ||||||||||
| Parameterized | When enabled, you may enter a parameterized cluster configuration. | ||||||||||
| Security Profile |
| ||||||||||
| Cluster Nodes | |||||||||||
Cluster Nodes | In this section, add IP addresses/hostnames of at least one of the nodes in the cluster. This address information is used by the Couchbase profile to connect to the cluster at workflow start , and to retrieve the IP addresses of the other nodes in the cluster. If the first node in the list cannot be accessed, the Couchbase profile will attempt to connect to the next one in order. This is repeated until a successful connection can be established. Hence it is not necessary to add all the nodes, but it is good practice to do so for a small cluster. For example, if there are just three nodes, you should add all of them. | ||||||||||
...
| Tip | ||
|---|---|---|
| ||
The Operation Timeout, Retry Interval Time, and Max Number Of Retries settings together with the Advanced tab setting mz.cb.lock.timeout.in.secs, work jointly. To understand how, see the following explanation. If you for example use the lookup function with transaction, a LOCK ERROR means that the lookup failed because there was already a transaction lock held on the object that the lookup was trying to get from Couchbase. That is, the lookup was not able to get a lock on the object. What is most important here is how the communication between In case you use the lookup function it works like this:
This is why the Operation Timeout parameter does not play a crucial role here. The Operation Timeout parameter is only used when Couchbase is stalling and does not send an answer for a long time. Assuming that the object is locked and the system received answer with LOCK_ERROR, will it will wait for the amont of time specified in Retry Interval Time and then retry the request towards Couchbase. This process is repeated until Max Number Of Retries is exhausted or the answer contains a successful result code and the object is retrieved from Couchbase. So, if you for example set Retry Interval Time to 100 ms and Max Number of Retries to 10, you get 100 ms * 10 retries = 1000 ms. However, from a MZ perspective, the timeout of 1000 ms is just for a single lookup attempt and not for the whole lookup operation. To clarify, if you get a failed lookupMany with LOCK_ERROR in the system log, it means that the lookup failed because it tried to get an object with a lock but failed after Max Number Of Retries. That is, some other process (or thread) was holding a lock on that particular object for longer than 1000 ms. This is possible if the Advanced tab setting mz.cb.lock.timeout.in.secs is larger than 1000 ms. In other words, you need to decide what is more important - that the operation succeeds or that the operation is fast. |
...
If the bucket you want to access in Couchbase does not exist, the Couchbase Couchbase profile can be used for creating the bucket in runtime for you, provided that the Admin User Name and Admin Password for your Couchbase cluster have been entered in the Management tab. If the bucket you want to access already exists in your cluster, these two fields do not have to be filled in.
...
To enable this property, set the value to com.digitalroute.mimexposer.statistics.MemDbStatistics or com.digitalroute.mimexposer.statistics.FileDbStatistics.
If you set the property value to com.digitalroute.mimexposer.statistics.MemDbStatistics, you can use the MIM agent to send statistics to System Insight. To do this, you must configure a workflow with a MIM agent. For further information, see 9.78.6 MIM Agent.
If you set the property value to com.digitalroute.mimexposer.statistics.FileDbStatistics, you can use the MIM agent to send statistics to System Insight or you can log to file. If you want to log to file only, you do not require the MIM agent. The log file is stored in $MZ_HOME/log per bucket, for example <bucket name>_couchbase_stats.log, and the file is flushed every 60 seconds by default. If you want to modify how often the file is flushed, set the property mz.cb.statistics.flush.period.in.seconds with the required value in the EC.
The Couchbase statistics that you can log include the following:
...