cmd, common, eth: cache orchestrator stake #1216
Conversation
kyriediculous
force-pushed
the
nv/cache-stake
branch
from
924ae6b
to
25bc310
Compare
kyriediculous
force-pushed
the
nv/cache-stake
branch
from
25bc310
to
9b93f63
Compare
|
Changed base branch to #1182 for now and added caching stake when starting the node. |
kyriediculous
force-pushed
the
nv/poolcache-update
branch
from
146902d
to
f48706c
Compare
kyriediculous
force-pushed
the
nv/cache-stake
branch
from
9b93f63
to
2374fb7
Compare
|
dropped the commits and rebased on latest #1182 |
| } | ||
|
|
||
| for _, o := range orchs { | ||
| go getStake(o) |
There was a problem hiding this comment.
Creating a goroutine for each query feels like a premature optimization at this point IMO since it introduces a piece of code that needs to be concurrency safe (and ideally we would test for it). Caching the stake for each active O isn't that time sensitive since it just happens on startup. Additionally, a simpler optimization that we could use in the future is to write a wrapper contract that aggregates all the stake values for a list of Os so that we can fetch the results with a single query.
There was a problem hiding this comment.
If I'm not mistaken go-sqlite does use a RWmutex so this should be thread safe regardless, since we're only writing the value to the DB and not memory.
There was a problem hiding this comment.
Yeah good point. On second thought, I'm fine with the concurrent requests used here 👍 with the wrapper contract as a nice to have optimization later on that removes the need for any concurrency code.
| } | ||
|
|
||
| for _, o := range orchs { | ||
| go getStake(o) |
There was a problem hiding this comment.
Yeah good point. On second thought, I'm fine with the concurrent requests used here 👍 with the wrapper contract as a nice to have optimization later on that removes the need for any concurrency code.
What does this pull request do? Explain your changes. (required)
This PR caches the stake for orchestrators in the active set whenever a new round event is emitted.
This can be both a removed log (re-org) or an added log (new round), in both cases we make an RPC call for the current round number and a subsequent RPC call for each O to fetch its stake for that specific round. We then update the orchestrator in the DB with the new stake.
Specific updates (required)
stakecolumn to theorchestratorstable and updatedUpdateOrchandSelectOrchsmethods accordinglyRoundsWatchersubscription toOrchestratorWatcherhandleRoundEventandcacheOrchestratorStaketoOrchestratorWatcherStubEthClient.GetTranscoderPoolForRoundDBOrchestratorPoolCacheis createdHow did you test each of these updates (required)
ran unit tests
Does this pull request close any open issues?
Fixes #1213
Checklist:
./test.shpass