Re: Diverting messages to non existing destination
Yes, that is what I am testing now. In the divert, before routing the message copy, a new RoutingContextImpl is created for it. To this new RoutingContextImpl, the original transaction is picked up from the original context, but currently not the ServerSession. So I am basically trying this in the divert: newContext.setServerSession(originalContext.getServerSession()); If I do this, auto-creation-check issued from postOffice during routing works according to the destinations auto-create address settings. If the destination does not exist and is not configured for auto-creation an "ActiveMQAddressDoesNotExistException" is returned to the sender.
Re: Diverting messages to non existing destination
can't you use the RoutingContext for anything like that? I thought we had already had some stuff on it. On Wed, Mar 20, 2024 at 9:41 AM Domenico Francesco Bruscino wrote: > > I think we should always reuse the server session of the original context > because it will be used to execute security checks before creating > addresses and queues. > > On Wed, 20 Mar 2024 at 09:35, Anton Roskvist wrote: > > > Thanks for your feedback, and yes, I also agree that adding a boolean to > > the divert-configis a good approach. > > > > There is one other thing about the implementation I'm thinking about > > though... after the divert sends the message copy over to postOffice it > > passes 2 additional auto-create-checks already. They are not passing > > because the diverted message does not have an associated serverSession > > which is where the actual auto-create-check is implemented. > > > > I can add the serverSession from the original context to the message copy, > > and then the auto-creation works without any additional changes to the > > divert. I do not know if this is okay to do though or if it has any > > potential side effects (all divert related tests I've run passes). > > > > If this is an acceptable way of doing it, a divert-config such as > > "reuse-user-session" could be used to gate new vs old behavior? > > -- Clebert Suconic
Re: Diverting messages to non existing destination
I think we should always reuse the server session of the original context because it will be used to execute security checks before creating addresses and queues. On Wed, 20 Mar 2024 at 09:35, Anton Roskvist wrote: > Thanks for your feedback, and yes, I also agree that adding a boolean to > the divert-configis a good approach. > > There is one other thing about the implementation I'm thinking about > though... after the divert sends the message copy over to postOffice it > passes 2 additional auto-create-checks already. They are not passing > because the diverted message does not have an associated serverSession > which is where the actual auto-create-check is implemented. > > I can add the serverSession from the original context to the message copy, > and then the auto-creation works without any additional changes to the > divert. I do not know if this is okay to do though or if it has any > potential side effects (all divert related tests I've run passes). > > If this is an acceptable way of doing it, a divert-config such as > "reuse-user-session" could be used to gate new vs old behavior? >
Re: Diverting messages to non existing destination
Thanks for your feedback, and yes, I also agree that adding a boolean to the divert-configis a good approach. There is one other thing about the implementation I'm thinking about though... after the divert sends the message copy over to postOffice it passes 2 additional auto-create-checks already. They are not passing because the diverted message does not have an associated serverSession which is where the actual auto-create-check is implemented. I can add the serverSession from the original context to the message copy, and then the auto-creation works without any additional changes to the divert. I do not know if this is okay to do though or if it has any potential side effects (all divert related tests I've run passes). If this is an acceptable way of doing it, a divert-config such as "reuse-user-session" could be used to gate new vs old behavior?
Re: Diverting messages to non existing destination
@Clebert Suconic I mean that I like your proposal to have the property in the divert On Tue, 19 Mar 2024 at 18:14, Clebert Suconic wrote: > @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 > > > 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 > > > > > >
Re: Diverting messages to non existing destination
@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 > 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 > > > 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 > > >
Re: Diverting messages to non existing destination
+1 for the new divert setting proposed by Clebert On Mon, 18 Mar 2024 at 18:15, Clebert Suconic 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 > 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 >
Re: Diverting messages to non existing destination
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 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
Re: Diverting messages to non existing destination
Hi, Sorry, I was not clear with my phrasing there. While trying out a solution where a diverts transformer changes message destination, I discovered this was an issue (for my use-case). So the change itself really is about handling the case where a "computed" destination is missing (as well as a case where the forwarding-adddress has gotten auto-removed), as well as adding documentation on how to route/compute destinations through the transformer in a divert.
Re: Diverting messages to non existing destination
Hi Anton, a divert could use a transformer to change a message destination. What are you using in your feature to change a message destination? Regards, Domenico On Mon, 18 Mar 2024 at 10:31, Roskvist Anton 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 >
Diverting messages to non existing destination
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
