-
-
Notifications
You must be signed in to change notification settings - Fork 281
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SQS QueueNotFoundStrategy auto-configure support. #1127
base: main
Are you sure you want to change the base?
Conversation
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.
Cool PR @wmz7year!
Left one comment for your consideration, please let me know your thoughts.
Thanks.
/** | ||
* The default {@link QueueNotFoundStrategy} | ||
*/ | ||
private QueueNotFoundStrategy queueNotFoundStrategy = QueueNotFoundStrategy.CREATE; |
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.
Your approach is solid, but we already define the default in ContainerOptions
.
I think we could be more defensive in this PR and not have a default set here, and instead only set these values to the Options objects if the user adds a value in the configuration.
Wdyt?
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.
Yes, ContainerOptions
is a good way to do this, but there are two methods to use SQS component: the first one is 'SqsMessageListenerContainerFactory', and the second one is SqsTemplate
.
If we only set QueueNotFoundStrategy
on ContainerOptions
, the SqsTemplate
won't work.
And also about the default value, currently both SqsTemplate
and SqsContainerOptions
are defined as default QueueNotFoundStrategy
to CREATE
value. To avoid making a change about this, I keep the default value here.
Check these out:
Line 632 in 0813661
private QueueNotFoundStrategy queueNotFoundStrategy = QueueNotFoundStrategy.CREATE; |
Line 128 in 0813661
private static final QueueNotFoundStrategy DEFAULT_QUEUE_NOT_FOUND_STRATEGY = QueueNotFoundStrategy.CREATE; |
TBH, I think QueueNotFoundStrategy
default value should be FAIL
. If someone first uses this component and doesn't have create queue permission, this will be more clearly stated in this context.
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.
And also about the default value, currently both SqsTemplate and SqsContainerOptions are defined as default QueueNotFoundStrategy to CREATE value. To avoid making a change about this, I keep the default value here.
Yup, my suggestion is we do not define a default for autoconfiguration. If the user sets a value we set it, otherwise we don't do anything. This way whatever is the default set for either the Template or Container is respected.
Makes sense?
I think QueueNotFoundStrategy default value should be FAIL
I see, the idea is to facilitate development time which is common, so users don't need to add logic to create queues when targeting e.g. LocalStack, or even AWS itself in a dev environment.
Maybe we can improve the error thrown in this case to make it more clear - let me know if you have any suggestion.
Thanks!
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.
Yup, my suggestion is we do not define a default for autoconfiguration
Yes, I can remove the default value for autoconfiguration. If I remove the CREATE
default strategy, the component's default behavior will still be CREATE
. So that's the reason I keep this default value to make it clearer. So I wonder if this is necessary or if I should just leave it here.
Maybe we can improve the error thrown in this case to make it more clear - let me know if you have any suggestion.
I agree. Maybe we can add a log when trying to create a new queue?聽 If the strategy is CREATE
and the user doesn't have create queue permissions, they will know why to throw a create queue permissions error while they just want to receive or send a message to the queue.
馃摙 Type of change
馃摐 Description
By default, when using SQS, even if a queue doesn't exist or is mispelled, it will automatically create a new queue, and there are no autoconfiguration options supported for this feature. So add a new auto-configure option to control the behavior of this.
馃挕 Motivation and Context
馃挌 How did you test it?
馃摑 Checklist
馃敭 Next steps