You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/core-token.md
+47-1Lines changed: 47 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,53 @@ token:
28
28
# leaseCleanupTickPeriod defines how often the eviction algorithm must be executed
29
29
# if leaseCleanupTickPeriod is zero, the eviction algorithm is never executed
30
30
leaseCleanupTickPeriod: 90s
31
-
31
+
# when we are interested to know when a tx reaches finality, we subscribe to the Finality Listener Manager for the finality event of that tx
32
+
# this configuration specifies the way the manager is instantiated, i.e. how it gets notified about the finality events, how often it checks
33
+
finality:
34
+
# the implementation of the finality manager. The finality manager keeps track of all subscribers that are interested to a transaction.
35
+
# These are the possible values:
36
+
# delivery: The manager subscribes to the delivery service and receives all final transactions.
37
+
# This manager keeps two structures: an LRU cache of recently finalized transactions, and a list of listeners that are waiting for future transactions.
38
+
# When a new block comes from the delivery service, we store all new transactions in the cache and notify all interested listeners
39
+
# When a client subscribes to the manager for a specific transaction, we go through the following steps, that correspond to all possible scenarios with decreasing probability:
40
+
# a) The transaction reached finality recently, so we perform a lookup. If not found, we go to step b.
41
+
# b) The transaction will reach finality shortly, so we append a listener and wait for a timeout. If the listener reaches timeout, we go to step c.
42
+
# c) The transaction reached finality long ago, so we query the whole ledger for this specific transaction. If the query returns no result, we go to step d.
43
+
# d) The transaction will reach finality at some point beyond the timeout or never, so we return Unknown. Then it is up to the client to either append another listener or accept that the transaction will never reach finality.
44
+
# committer: The manager subscribes to the commit pipeline and receives all finalized transactions.
45
+
# If we subscribe for a transaction that hasn't been finalized yet, we will get notified once it reaches the commit pipeline.
46
+
# For listeners that haven been invoked yet, either the transaction hasn't been finalized or it was finalized before we subscribed.
47
+
# For this reason, there is a periodic polling period (1s) that queries all txIDs for which there is a pending listener and invokes the listeners for the ones found.
48
+
# Once we get notified about finality, we try (repeatedly) to fetch the additional tx information needed from the vault (e.g. transactionRequest)
49
+
# If we work without replicas, there is no need to try more than once to fetch the additional tx information, because the finality notification and vault update happen in sync.
50
+
# It is only needed in case we have replicas, where another replica may have updated the vault shortly before.
51
+
type: delivery
52
+
# Only applicable when type = 'committer'
53
+
committer:
54
+
# how many times should we try to fetch the additional tx information from the vault
55
+
maxRetries: 3
56
+
# how long should we wait before retrying
57
+
retryWaitDuration: 5s
58
+
# Only applicable when type = 'delivery'
59
+
delivery:
60
+
# how many goroutines should process incoming transactions in parallel. Defaults to 1
61
+
mapperParallelism: 10
62
+
# how many blocks can we process in parallel when they arrive from the delivery service
63
+
# if the value is <= 1, then blocks are processed sequentially.
64
+
# This is the suggested configuration if we are not sure about the dependencies between blocks.
65
+
# The total go routines processing transactions will be blockProcessParallelism * mapperParallelism
66
+
blockProcessParallelism: 1
67
+
# how many transactions should we guarantee that we keep in our recent cache
68
+
# if the transaction is not among these elements we proceed to the step b, as described above.
69
+
# if lruSize and lruBuffer are not set, then we will never evict past transactions (the cache will grow infinitely)
70
+
lruSize: 30
71
+
# eviction will happen when the cache size exceeds lruSize + lruBuffer
72
+
lruBuffer: 15
73
+
# when we can't find a transaction in the cache most probably it is about to become final
74
+
# we will listen for this amount of time and then we will query the whole ledger, as described in step c.
75
+
# if the timeout is not set, then the listener will never be evicted and we will never proceed to step c.
76
+
# We will wait forever for the transaction to return (as is done for the 'committer' type)
77
+
listenerTimeout: 10s
32
78
tms:
33
79
mytms: # unique name of this token management system
34
80
network: default # the name of the network this TMS refers to (Fabric, Orion, etc)
0 commit comments