-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[Pulsar IO] Allow routing key per message to RabbitMQ sink connector #5890
Merged
codelipenghui
merged 2 commits into
apache:master
from
bluelabs-eu:rabbitmq_routing_key
May 19, 2020
Merged
[Pulsar IO] Allow routing key per message to RabbitMQ sink connector #5890
codelipenghui
merged 2 commits into
apache:master
from
bluelabs-eu:rabbitmq_routing_key
May 19, 2020
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
alex-rufo
changed the title
Allow routing key per message to RabbitMQ sink connector
[Pulsar IO] Allow routing key per message to RabbitMQ sink connector
Dec 18, 2019
tuteng
added
area/connector
type/enhancement
The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages
labels
Dec 19, 2019
run cpp tests |
run cpp tests |
LGTM |
tuteng
approved these changes
Jan 13, 2020
retest this please |
murong00
approved these changes
Jan 13, 2020
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.
LGTM+1
run cpp tests |
codelipenghui
approved these changes
May 19, 2020
nicolo-paganin
pushed a commit
to oncodeit/pulsar
that referenced
this pull request
May 22, 2020
…pache#5890) ### Motivation With the current RabbitMQ sink connector, all messages are forwarded to an exchange with the same routing key (specified in the configuration). It would be great to give a bit more flexibility and allow the use of different routing keys for different messages on the same topic. ### Modifications The creation of the queue has been removed from the sink, all messages will be forwarded to the exchange and each consumer will create it's on queue + binding. The configuration has been modified to reflect those changes: added the exchange type and queue name is just required for the source connector.
nicolo-paganin
pushed a commit
to oncodeit/pulsar
that referenced
this pull request
May 22, 2020
…pache#5890) ### Motivation With the current RabbitMQ sink connector, all messages are forwarded to an exchange with the same routing key (specified in the configuration). It would be great to give a bit more flexibility and allow the use of different routing keys for different messages on the same topic. ### Modifications The creation of the queue has been removed from the sink, all messages will be forwarded to the exchange and each consumer will create it's on queue + binding. The configuration has been modified to reflect those changes: added the exchange type and queue name is just required for the source connector.
Huanli-Meng
pushed a commit
to Huanli-Meng/pulsar
that referenced
this pull request
May 27, 2020
…pache#5890) ### Motivation With the current RabbitMQ sink connector, all messages are forwarded to an exchange with the same routing key (specified in the configuration). It would be great to give a bit more flexibility and allow the use of different routing keys for different messages on the same topic. ### Modifications The creation of the queue has been removed from the sink, all messages will be forwarded to the exchange and each consumer will create it's on queue + binding. The configuration has been modified to reflect those changes: added the exchange type and queue name is just required for the source connector.
huangdx0726
pushed a commit
to huangdx0726/pulsar
that referenced
this pull request
Aug 24, 2020
…pache#5890) ### Motivation With the current RabbitMQ sink connector, all messages are forwarded to an exchange with the same routing key (specified in the configuration). It would be great to give a bit more flexibility and allow the use of different routing keys for different messages on the same topic. ### Modifications The creation of the queue has been removed from the sink, all messages will be forwarded to the exchange and each consumer will create it's on queue + binding. The configuration has been modified to reflect those changes: added the exchange type and queue name is just required for the source connector.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/connector
type/enhancement
The enhancements for the existing features or docs. e.g. reduce memory usage of the delayed messages
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.
Motivation
With the current RabbitMQ sink connector, all messages are forwarded to an exchange with the same routing key (specified in the configuration). It would be great to give a bit more flexibility and allow the use of different routing keys for different messages on the same topic.
Modifications
The creation of the queue has been removed from the sink, all messages will be forwarded to the exchange and each consumer will create it's on queue + binding.
The configuration has been modified to reflect those changes: added the exchange type and queue name is just required for the source connector.