Queue: Better management of the timeout
If Jira is slow, then Confluence times-out and believes the messages weren't treated, and retries them 3 minutes later.
See this page for all explanations about our changes:
Starving the connection pool
In Jira, restrict the message receival to 1 worker. This ensures we don’t starve the connection pool with n workers.
Ensure the emitter’s timeout is much longer than the recipient (4x30s),
Ensure the recipient hastily stops processing messages upon reaching the timeout (30s), returning them as NOT_EXECUTED, so the other messages are correctly marked as DONE in the emitter.
It still leaves a gap: If Jira takes 40s to respond every time, and the network cuts the connection at 30s every time, then Confluence is not aware that the messages have been processed, and will send the same messages next time. There is no workaround for this gap.
A possible solution would be to stream the results back to Confluence (same as long-polling methods), but this will introduce another class of problems.
Don’t forget .