-
Notifications
You must be signed in to change notification settings - Fork 336
Enable Pub/Sub message ordering for publishing #408
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
Conversation
Introduces `GcpPubSubHeaders.ORDERING_KEY` header that will be automatically applied to the `PubsubMessage` up conversion. Also, introduces `spring.cloud.gcp.pubsub.publisher.enable-message-ordering` property to enable message ordering on the `Publisher`. First step in addressing: #85.
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 good, couple of minor things.
//tag::publish_ordering[] | ||
Map<String, String> headers = Collections.singletonMap(GcpPubSubHeaders.ORDERING_KEY, "key1"); | ||
pubSubTemplate.publish(topicName, "message1", headers).get(); | ||
pubSubTemplate.publish(topicName, "message2", headers).get(); |
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.
Maybe add a comment to explain that messages with the same ordering key will be delivered in the same order they were sent.
/** | ||
* Enable message ordering setting. | ||
*/ | ||
private Boolean enableMessageOrdering; |
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.
why not a primitive boolean? Default state is false; would be no need to mess with nulls.
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.
+1 yeah would also prefer the primitive boolean to avoid implying that not setting it is different than setting it to false
.
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.
Sometimes we follow the pattern that is to allow not setting it, so that the client library default can be used automatically. Otherwise, we have to maintain the default, which in this case probably doesn't matter.
publisherBuilder.setBatchingSettings(this.batchingSettings); | ||
} | ||
|
||
if (this.enableMessageOrdering != null) { |
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.
If it's primitive, then we don't need to check for null here, just straight set the value, or, to be extra safe, check if true.
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.
The question is whether we want to allow not setting the value at all and letting the client lib control the default.
.build()); | ||
|
||
this.adapter.handleMessage(this.message); | ||
verify(this.pubSubTemplate, times(1)) |
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.
can omit times(1)
SonarCloud Quality Gate failed. |
Introduces `GcpPubSubHeaders.ORDERING_KEY` header that will be automatically applied to the `PubsubMessage` up conversion. Also, introduces `spring.cloud.gcp.pubsub.publisher.enable-message-ordering` property to enable message ordering on the `Publisher`. First step in addressing: GoogleCloudPlatform#85.
Introduces
GcpPubSubHeaders.ORDERING_KEY
header that will be automatically applied to thePubsubMessage
up conversion.Also, introduces
spring.cloud.gcp.pubsub.publisher.enable-message-ordering
property to enable message ordering on thePublisher
.First step in addressing: #85.