check the use of map/channel and the possibility to replace it with a cache

[adecaro]

Currently, we use maps (in go map), channels (in go chan), and platform/common/utils/cache in multiple parts of the code including the token-sdk.
This Issues asks to the following:

• Identify the location where a they are used
• Check if entries are ever deleted
• Evaluate the possibility to replace them with a cache
• Add metrics to measure it.

Let's do the same work also for the Token-SDK.

[adecaro]

so, every time we encounter the use of one of the above data structures, I suggest to write a benchmark test to see what happens when we replace the cache with a different implementation.

[kushnireyal]

Token-SDK analysis by ChatGPT:

Below is a unified, side-by-side synthesis of both sets of recommendations. Where my thinking shifted, I’ve noted it.

---

1. 🔴 Top-Tier, Immediate Focus

File	Var / Channel	Reason for High Priority	Change from Previous Analysis
token/services/certifier/interactive/client.go	eventOperationMap	Long-lived map, never mutex-protected or pruned.	New high-risk item uncovered in the final scan.
token/sdk/vault/provider.go	vaultCache	Name implies cache; unbounded growth; no deletes; mutex-protected but no eviction or metrics.	Same as before.
token/services/identity/provider.go	isMeCache	Classic lookup cache with no expiry; heavy concurrent access; no eviction metrics.	Same as before.
token/services/selector/sherdlock/fetcher.go	cache	Real cache semantics; no TTL/LRU; unbounded.	Same as before.
token/services/network/fabric/lookup/channelllm.go	listeners	Shared listener registry; deletions only on explicit removal; could leak stale entries.	Same as before.

Why these?

• Unbounded growth without any automatic eviction.
• Production-critical code paths, often shared across goroutines.
• No built-in metrics for size, hits/misses, or evictions.

---

2. 🟡 Secondary, Medium-Priority Review

File	Var / Channel	Notes	Change from Previous Analysis
token/services/network/fabric/lookup/deliveryqs.go	ch	Buffered channel for key-info; closed properly but no metrics.	Promote from low to medium, needs queue metrics.
token/services/network/fabric/finality/deliveryqs.go	ch	Same as above.	Same.
token/services/identity/idemix/cache/cache.go	cache	Buffered cache channel; unclear eviction/drain logic.	Same.
token/services/selector/simple/inmemory/locker.go	locked	Manually cleared, but could benefit from expiration semantics or metrics.	Same.
token/services/network/fabric/lookup/deliveryllm.go	txInfos	Per-call map of writes; no delete—low risk if scoped properly.	Newly surfaced; bump to medium for audit.
token/services/network/fabric/finality/deliveryflm.go	txInfos	Same as above.	Newly surfaced; bump to medium for audit.

Why these?

• Either closed/deleted, but still long-lived or high-throughput.
• Lacking observability around queue depth or map size.
• Could become medium-risk under heavy load or error conditions.

---

3. 🟢 Lower Priority / Low-Risk

File	Var / Channel	Reason	Change from Previous Analysis
All integration/… test files	various maps/chan	Test scaffolding—short-lived; isolated to test suites.	Same.
token/services/ttx/marshaller.go	v (map)	Ephemeral in serialization; GC-collected at function exit.	Same.
token/core/common/loaders.go	tokens (map)	Local per-call; no retention beyond function scope.	Same.
token/core/service.go	factories (map)	Static registry; small and fixed size.	Same.
token/services/db/sql/common/transactions.go	acks (map)	Local to transaction method; no retention.	Downgraded from medium, since scoped and ephemeral.
token/services/db/sql/common/tokens.go	tokenMap, infoMap, certificationMap	Per-call, ephemeral.	Downgraded similarly.
token/services/db/sql/multiplexed/driver.go	drivers (map)	Loaded once at startup; static.	Same.

Why these?

• Bound by function scope or size.
• Either cleaned up automatically (GC) or never grows beyond a small, fixed set.

---

Summary of Changes

• New High-Priority:
  • eventOperationMap (no mutex or cleanup)
• Promoted:
  • Delivery queues (deliveryqs.go) to medium for metrics
  • txInfos maps in LLM paths to medium for audit
• Demoted:
  • DB transaction maps (acks, tokenMap, etc.) to low, since they’re truly ephemeral

---

✅ Combined Next-Steps

1. Refactor & Cache Replacement
   • Swap out eventOperationMap, vaultCache, isMeCache, selector…cache and listeners maps for secondcache.New(...) (or wrap with RWMutex plus metrics).
2. Instrumentation
   • Add Prometheus metrics for:
     • Cache size (Gauge)
     • Cache hits/misses (Counter)
     • Evictions (Counter)
     • Channel depth (Gauge)
3. Audit & Validate Medium Items
   • Ensure deliveryqs channels are drained and closed in all paths.
   • Confirm txInfos maps do not escape function scope or add explicit delete calls if they do.

Let me know which refactor or metric you’d like to tackle first, and I can draft the precise code changes!

[AkramBitar]

General agreed strategy (@adecaro, @kushnireyal, and @AkramBitar):

1. For each cache, measure its current hit rate with the respect to the size using. To do so, we need to use the FSC metrics https://github.com/hyperledger-labs/fabric-smart-client/blob/main/docs/platform/view/monitoring.md. If a metric is absent for that cache we need to add.
2. If the cache has low hits despite its size, we can remote it.
3. If the cache has high hits and lots of contention, we can benchmark which cache can better serve the requirements.

[adecaro]

@AkramBitar , @kushnireyal , how do we move next?

[AkramBitar]

@adecaro I will start with isMeCache cache. Will add the metrics for Cache size (Gauge) and Cache hits/misses (Counter).
Run workloads of IDAP or and check the metrics (we need a real access pattern to this cache). Then, we will check other caches based on priority that we will set with you.

[AkramBitar]

• Build MetricsCache
• Replace isMeCache with MetricsCache, run IDAP workload generator, analyze the results