Previous issue: #2561323: Add '--no-reset-expired' to allow not to reset expired items from queue table

The rationale behind the above feature can be true or false for different queues on the same installation, depending on queue latency, item lease time, failed item ratio, etc. Useful for heavy/long worker function queues or when lots of items are failing, since queue processing could get stuck always processing failed items (happening to me now).
Thus, having a queue-by-queue 'do not reset expired items' kind of feature would allow still finer tunning of mob_queue processing.

UX-wise it can be a hidden option initially to avoid cluttering the UI, which would need a table or similar, perhaps on a separate, followup issue with a bit of thought on its own.

Functionally, it would be implemented as follows:
1.- If '--no-reset-items' present, go ahead and skip any further reset logic. No items will be reset, never.
2.- Otherwise, read from a 'mob_queue_QUEUE_NAME_reset_items' boolean variable, defaulting to TRUE to preserve current behaviour.
3.- Only for queues where 2 is TRUE, reset expired items at the reset query. Bonus: reset operations UPDATE queries will affect fewer rows (improving locks acquisition) and depending on configuration will avoid undesired/unnecessary updated rows. The query will be fired only once before the main loop as now, but narrowing the WHERE clause.

To skip resetting a specific queue items would work only when 2 is set to FALSE.
Currently, the only loose end now for me is what to do with '--no-reset-items'. Make it to have priority on individual, queue-level settings or not? What do you think?

Comments

amontero created an issue.

wuinfo - Bill Wu’s picture

Nice to have the feature.

1. is already implemented. The option is no-reset-expired at #2561323.

amontero’s picture

The numbered list was meant to be a step-by-step code description. Sorry for the misunderstanding.

I'm posting the idea here to discuss an appropiate implementation and figure out the details.