Uniqueness Checker

The uniqueness checker and backing store metrics are from the perspective of uniqueness processing, which runs independently of the flow Communication between participants in an application network is peer-to-peer using flows. processing.

The uniqueness checker handles the business logic of uniqueness checking. The implementation is batched at two levels and three categories of metrics are provided:

• Metrics starting with uniqueness_checker_batch relate to “top level” metrics, which apply to a single batch processed by the uniqueness checker. As a batch may contain requests from different notary Corda’s uniqueness consensus service. The notary’s primary role is to prevent double-spends by ensuring each transaction contains only unique unconsumed input states. services and/or virtual nodes, these metrics provide no context as to the identities of the batch being processed.

• Metrics starting with uniqueness_checker_subbatch relate to “sub-batch level” metrics. Each sub-batch represents a partition for each notary virtual node The combination of the context of a user and the ephemeral compute instances created to progress a transaction on that identity's behalf. identity within a batch. The virtual node identity is captured via the existing virtualnode.source tag.

• Metrics starting with uniqueness_checker_request relate to metrics applicable to specific requests within a sub-batch, such as the result of a request. Like the sub-batch metrics, these are also associated with the virtualnode.source tag.

Tags:

• virtualnode_source: The virtual node identity.
• result_type: It can be used to understand the number of successful vs failed requests, and the type of failures.
• duplicate: This tag is set to true if the uniqueness checker has seen a request for this transaction before, and is therefore simply returning the original result. Otherwise, it is false.