You posted an example using catch-all wildcard config where the config would have likely applied to both the original queue, and their expiry queue, and in such a way it could cause re-expiry and would seem to even create a loop as Domenico covered. I can certainly see argument for that sometimes being unintended or unexpected. Though, I could also see the view that it is just doing exactly what was configured in the settings in the way the settings note they will.
However what if someone instead explicitly configured [only] their expiry queues settings to apply a certain additional expiration, e.g a longer one than originally, and also e.g didnt have an expiry queue set for their expiry queue? I could also see use cases like that, where messages are originally expired into an expiry queue after a shorter normal processing period, and then are allowed to sit there for at most <longer time foo> for inspection etc before being expired again into oblivion if not otherwise handled. Then much the same for the DLQ case. It similarly doesnt seem unthinkable someone might want to (or may already) apply expiration to those in some cases. Might not be the typical use cases, but it doesnt seem entirely unlikely. Would those still be possible with whatever you intend, or are you just thinking on a blanket ignore of those settings for DLQ/expiry queues? On Wed, 20 Nov 2024 at 14:36, Clebert Suconic <clebert.suco...@gmail.com> wrote: > > I think it should not apply. But I wanted to check if anyone is against my > opinion. > > Clebert Suconic > > > On Wed, Nov 20, 2024 at 9:29 AM Clebert Suconic <clebert.suco...@gmail.com> > wrote: > > > What about expiry of a DLQ? > > > > When moving a message to DLQ, the following code here would also > > applyExpiration if addressSettings/expiry-delay is set on the DLQ > > address: > > > > > > https://github.com/apache/activemq-artemis/blob/b084eac71d168303019b799e0d267210c19677f7/artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java#L1167-L1171 > > > > On Wed, Nov 20, 2024 at 1:00 AM Domenico Francesco Bruscino > > <bruscin...@gmail.com> wrote: > > > > > > We should avoid the expiry of the expiry because it could cause the loss > > of > > > the original address/queue destination and infinite expiry loops. > > > > > > Domenico > > > > > > On Wed, 20 Nov 2024 at 04:56, Clebert Suconic <clebert.suco...@gmail.com > > > > > > wrote: > > > > > > > Say you set the expiry delay on the address-settings. > > > > > > > > > > > > address-settings.#.expiryDelay=5000 > > > > address-settings.#.expiryQueue=TheExpiryQueue > > > > > > > > > > > > now, you send a message with an expiry delay as 2 seconds... > > > > > > > > > > > > 2 seconds from now, the message expiry will move the message > > TheExpiryQueue > > > > > > > > > > > > > > > > > > > > The system is currently applying 5 seconds expiry on the message > > > > routed to TheExpiryQueue. I even open a JIRA: > > > > https://issues.apache.org/jira/browse/ARTEMIS-5167 > > > > > > > > > > > > I don't think this is correct, however an user could use the > > > > unintended feature (aka bug) to set the expiration of the expired > > > > message. > > > > > > > > > > > > Should I avoid setting the expiry of the expiry? Does anyone see a > > > > valid use case on such an unintended feature? > > > > > > > > > > > > Currently AutoCreateExpiryResourcesTest::testWithJMSFQQN is failing > > > > because of this. > > > > > > > > > > > > > > > > -- > > > > Clebert Suconic > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org > > > > For additional commands, e-mail: dev-h...@activemq.apache.org > > > > For further information, visit: https://activemq.apache.org/contact > > > > > > > > > > > > > > > > > > > > -- > > Clebert Suconic > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@activemq.apache.org For additional commands, e-mail: dev-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
