Learn more about these different git repos.
Other Git URLs
The impact of this is that the broker thinks it is being instructed to never expire messages.
If a consumer comes online, establishes a queue to consume some messages as a test, and then goes offline never to be heard from again, then the queue it created just fills and fills and fills until an admin has to come along and destroy it.
If we start setting a reasonable expiration header for messages, that should ease some of the load on activemq admins.
See https://pagure.io/koji/pull-request/3121
Metadata Update from @tkopecek: - Custom field Size adjusted to None - Issue set to the milestone: 1.28
Ralph, is this a bug in Proton (or somewhere else)? Since Koji is not doing anything special, it seems like all Proton apps would have this same issue.
I suppose it is, yes -- but, I haven't done the work to find if there's an upstream proton tracker for it or not.
I played around with Proton's helloworld.py example and Wireshark. Turns out that the Proton Python client only sends a ttl header on the wire if the .ttl property is non-zero. If it's zero (the default), Proton does not send any ttl header.
ttl
.ttl
Did someone see Koji sending a message to a broker with an explicit ttl?
Generally I think it's reasonable for broker admins to determine how long messages should queue, rather than building these settings into every application. Those values could change as broker admins deploy more hardware, etc.
@ralph I concur to Ken here - is it really something we should set? How different brokers react to this? If there is some TTL limit on broker side - is it cutoff for TTL we set or is our TTL superior?
I've been testing the protonmsg plugin recently with ActiveMQ, Artemis, and RabbitMQ.
I also talked with Red Hat's ActiveMQ admins about expiring messages. It sounds like they have a robust server-side solution in place now for deleting abandoned consumer VirtualTopic queues so those don't cause resource issues.
(For example, the RH admins delete all my abandoned VirtualTopic.kdreyer consumer queues after one hour of no connections)
VirtualTopic.kdreyer
Metadata Update from @tkopecek: - Issue set to the milestone: 1.29 (was: 1.28)
Metadata Update from @tkopecek: - Issue close_status updated to: Dropped - Issue status updated to: Closed (was: Open)
I've dropped the issue as it is not a problem on koji/proton side and it should be solved by messaging server configuration.
Metadata Update from @tkopecek: - Issue set to the milestone: None (was: 1.29)
Login to comment on this ticket.