Currently, we have an early basic.ack which runs before the processReport method. We thought that this was working pretty well, but realized recently (see dataone-indexer 118) that is is likely the timeout issues we still occasionally see are coming up because rabbitmq sends another message as soon as the previous one was acked, thus starting the timeout timer again.
Ideally, the worker would reject messages that come when it isn't ready. We can use threads where one thread is either accepting or rejecting messages based on whether the second thread is alive.
Currently, we have an early
basic.ackwhich runs before theprocessReportmethod. We thought that this was working pretty well, but realized recently (see dataone-indexer 118) that is is likely the timeout issues we still occasionally see are coming up because rabbitmq sends another message as soon as the previous one was acked, thus starting the timeout timer again.Ideally, the worker would reject messages that come when it isn't ready. We can use threads where one thread is either accepting or rejecting messages based on whether the second thread is alive.