Maybe fixing #3120.
deafult -> default
deafult
default
I've tested this with a local RabbitMQ setup and it works. Messages are expired in the queue after the configured time.
rebased onto c1445b60bca62f4ddb8a7d3cd5431da19267b1d7
Fixed in c1445b60bca62f4ddb8a7d3cd5431da19267b1d7.
Does it make to expand it a bit and add a value which is telling proton to not set ttl at all? e.g. ttl = None? Otherwise we are always enforcing some value indepently on broker's configuration.
ttl = None
Koji sends no ttl value. It just uses Proton's defaults. On the wire, Proton sends no expiry header at all.
Also, since Koji sends to a topic://, those messages should introduce no load on a simple broker. (When I tested this PR with RabbitMQ, I hacked the plugin to use a queue:// prefix instead, just to see if the messages would expire, and they do with this PR.)
topic://
queue://
The problem is that broker administrators set up VirtualTopics to start queuing arbitrary messages in queues that anyone can create and abandon. Fixing all producers is whack-a-mole and complicates producer implementations. The QE cost of adding this to Koji means we'd need to set up ActiveMQ and configure VirtualTopics.
Given RH IT's recent improvements with the Network of Brokers, I think this problem is solved now for Red Hat. Right Ralph?
I do think it's worth updating Proton's API documentation to explain what "0" and "None" imply on the wire. I'll submit a PR for that to https://github.com/apache/qpid-proton
The reason why I am hesitant to add another knob here is that I want this plugin to be simpler to deploy, to give users fewer options, making Koji easier to use.
(There are already so many "koji event" plugins floating around - Fedora, CentOS, and Rocky Linux all have written their own that are independent from the protonmsg one in-tree.)
Proton does not accept None, it bails with TypeError.
None
TypeError
I've documented the default proton behavior here: https://github.com/apache/qpid-proton/pull/348
Pull-Request has been closed by tkopecek
Maybe fixing #3120.