When ingesting timeouts, TimeoutPersisterReceiver queries in tight loop

[DavidBoike]

In the TimeoutPersisterReceiver, when ingesting a large amount of timeouts into persistence, the value of timeoutPushed is held at true, which results in no code path where nextRetrieval is modified. This results in a tight loop where the timeout persistence is queries over and over, even if the timeouts being added are far into the future.

Who's affected

Users who register large amounts of saga timeouts or deferred messages.

Symptoms

When logging at INFO level or above, nothing would be evident in an endpoint's logs, because the TimeoutPersisterReceiver only logs at DEBUG level. At the DEBUG mode, rapid requerying of timeouts would be observed. Alternatively, you may notice undue load on the timeout persistence (SQL Server, RavenDB, etc.) when ingesting timeouts, although it would be easy to misattribute this to the actual writing of timeouts.

[timbussmann]

is v6 affected by this too?

[DavidBoike]

I don't know yet, will be checking that out for sure.

[DavidBoike]

V6 is not affected by this. V6 does not have the timeoutPushed concept or the tricky if/then logic based on it. It only has NextRetrieval, which is simply backed up if a timeout comes in that's before the current value. Much better IMO, and my same test harness proves it out.

[danielmarbach]

Nice @DavidBoike

[DavidBoike]

Updated the description with Who's affected and Symptoms information for possible release notes.

[andreasohlund]

Reading the updated description and @bording comment on the PR I'm 👍 to go ahead and release this

[DavidBoike]

Will release on my Monday morning.

[DavidBoike]

This is now released in NServiceBus 5.2.15.