@dom Anton had added an address setting. Perhaps we could have the property in the divert instead ?
On Tue, Mar 19, 2024 at 4:01 AM Domenico Francesco Bruscino < bruscin...@gmail.com> wrote: > +1 for the new divert setting proposed by Clebert > > On Mon, 18 Mar 2024 at 18:15, Clebert Suconic <clebert.suco...@gmail.com> > wrote: > > > I think we should do 1. > > at that point we look for the address-settings on auto-create, if > > auto-create is on, we should then create it. > > > > > > However, to unlock the situation for those who may disagree.. Can't we > > add a Setting to the Divert itself. > > > > we could have a boolean on the Divert deployment on check-auto-create > > flags... and only do that logic if such flag is on? > > > > > > that way you could also bypass any additional checks for those who > > don't need the functionality. > > > > > > On Mon, Mar 18, 2024 at 5:30 AM Roskvist Anton <anton.roskv...@volvo.com > > > > wrote: > > > > > > Hi all, > > > > > > I'm working on a feature for Artemis where the use-case is the ability > > to compute or alter a messages destination through a divert. In doing so > > there is a possibility that the new destination might not exist on the > > broker. There is some debate around how to handle this. > > > > > > The current behavior is to silently drop the messages in this scenario. > > > > > > There are currently two proposed solutions: > > > > > > 1. Handle it with the already existing "auto-create" logic, which is > > subject to the address settings auto-create-addresses and > > auto-create-queues. > > > -Downside is that this might break a pre-existing use-case where these > > messages are expected to fail. > > > > > > 2. Gate the same functionality with a new address-setting like: > > "auto-create-divert-destinantions" > > > -Downside here is that since the destination is not known beforehand, > > lookups for the particular address settings in question will either be > made > > on each diverted message or some additional mechanism has to be put in > > place to manage this. > > > > > > I'm looking for feedback on how you all feel this should be handled. > > > > > > Personally I feel the current behavior is a bit strange and should be > > considered a bug, so I would prefer solution 1. To handle the case where > > someone might expect this type of behavior, a note about this change > could > > be added to the brokers versions-page about the change in semantics along > > with a suggestion to use something like a "black-hole" destination for > > these messages instead. > > > > > > Thoughts? > > > > > > This email message (including its attachments) is confidential and may > > contain privileged information and is intended solely for the use of the > > individual and/or entity to whom it is addressed. If you are not the > > intended recipient of this e-mail you may not disseminate, distribute or > > copy this e-mail (including its attachments), or any part thereof. If > this > > e-mail is received in error, please notify the sender immediately by > return > > e-mail and make sure that this e-mail (including its attachments), and > all > > copies thereof, are immediately deleted from your system. Please further > > note that when you communicate with us via email or visit our website we > > process your personal data. See our privacy policy for more information > > about how we process it: https://www.volvogroup.com/en-en/privacy.html > > > > > > > > -- > > Clebert Suconic > > >
