Binding multicast implementation #292
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Alan Conway <[email protected]>
Signed-off-by: Alan Conway <[email protected]>
Signed-off-by: Alan Conway <[email protected]>
StructMessage and EventMessage are intended to be full implementations of the Message interface that are independent of any transport and can be used to hold a copy of a message in memory independently of the life of an incoming transport message (e.g. for multicast, queuing etc.) CopyMessage copies an incoming Message, the copy can be read many times and is independent of the original message lifecycle (e.g. you might Finish() the original before you're done multicasting the copy depending on policy) They are a lot like your MockXMessages but they are not mocks, they're complete Message implementations. Possibly there's some code overlap that can be cleaned up. Please review the code carefully. I like what you've done to reduce copying but there was a lot to take in, so this is a bit rushed. One question: I intended for 2 types of message representation - Binary and Structured. Message.Event() and EventMessage were really just implementations of Binary encoding - not meant to be a third representation. I think you could drop Message.Event() now that you have ToEvent(Message) so bindings only have to implement the methods Structured() and Binary(). Signed-off-by: Alan Conway <[email protected]>
Signed-off-by: Francesco Guardiani <[email protected]>
Test integration CopyMessage + WithAcksBeforeFinish Signed-off-by: Francesco Guardiani <[email protected]>
Added multi senders Signed-off-by: Francesco Guardiani <[email protected]>
* CopyMessage moved in buffering submodule * CopyMessage splitted to CopyMessage and BufferMessage (one binds the lifecycle, the other no) * CopyMessage & BufferMessage implements buffer pooling to decrease memory allocations * EventMessage, ToEvent & Transport adapter moved in event submodule Signed-off-by: Francesco Guardiani <[email protected]>
slinkydeveloper
changed the title
Signed-off-by: Francesco Guardiani <[email protected]>
Signed-off-by: Francesco Guardiani <[email protected]>
|
A couple of data: Comparison with #282 & #283#282 still remain the fastest, but this PR is faster than #283 and allocates less mostly because of pooling. Some limit cases (focused in particular on high parallelism + high number of senders):
All results: Binary buffered representationUsing cloudevents.Context in buffered binary 62bfa7b: Using plain map b766a97: |
slinkydeveloper
changed the title
|
This all LGTM at quick look, I will take a closer look in a bit. |
|
LGTM |
This was referenced Jan 29, 2020
This was referenced Feb 4, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Replaces #282 & #283
Starting from @alanconway's work in #283:
WithAcksBeforeFinishfrom Enable a binding.Message to be consumed more times #282CopyMessageto drain the input message without binding the lifecycle (it explicitly require the manual invocation ofinputMessage.Finish())BufferMessageto drain the input message binding the lifecycle of the new message with the input messageEventMessage&BindingTransportadapter are under binding/event, buffering methods under binding/buffering & mocks in binding/testBindingTransport