-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process messages concurrently #288
Conversation
This reverts commit 3b0c438.
relayer/application_relayer.go
Outdated
var eg errgroup.Group | ||
for _, msg := range msgs { | ||
eg.Go(func() error { | ||
return r.ProcessMessage(msg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upgraded to go 1.22 so that this closure captures the value of msg
on each iteration, rather than the variable itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an interesting change for a language upgrade. I'm surprised if this change doesn't break some apps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cam-schultz There's a flag you can set in 1.21
that enables this feature, so we can keep our versions consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for pointing that out @geoff-vball . I elected to go with the workaround of assigning a local variable in each iteration rather than include that experimental flag in the build, since we're trying to lock into stable language features.
Refactor application relayers
7d2f8ee
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this was merged before I finished my second pass, but it LGTM. Just a minor nit comment.
|
||
// Check for the expected number of responses, and clear from the map if all expected responses have been received | ||
// TODO: we can improve performance here by independently locking the response channel and response count maps | ||
responses := h.responsesCount[requestID] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: perhaps add an "ok" check on the map lookup just to defensively check for logic errors.
Why this should be merged
Fixes #31
Refactors
ApplicationRelayer
to be more akin to a standalone worker, as opposed to a composite piece of a subnetListener
How this works
ProcessHeight
andProcessMessage
toApplicationRelayer
.ProcessHeight
callsProcessMessage
in a separete goroutine for each Warp message in the block.ProcessMessage
can be called on its own (as is the case for manual Warp message relays)ApplicationRelayer
fromListener
,ExternalHandler
, andMessageManager
ExternalHandler
adds the methodRegisterRequestID
, which routes all inbound app responses for that ID to the caller. Used to route messages directly to the initiatingApplicationRelayer
MessageManager
is now a factory forMessageHandlers
, an ephemeral type that handles message processing for a single Warp messageCheckpointManager
simplified to only perform periodic writes. The previous prepare-stage-commit flow is now encapsulated inApplicationRelayer.ProcessHeight
BatchMessage
e2e test that sends multiple Teleporter messages in a single transaction. This tests concurrent message processing within a single block. Solidity infra added totests/
to support the newBatchCrossChainMessage
contract.How this was tested
CI
Added batch tx e2e test
TODO: before/after througput testing (see #185)
How is this documented
N/A. No functional changes, pure throughput