You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to support legacy endpoints which do not declare the delay infrastructure, a delayed message sender declares the binding between the delay infrastructure and the receiving endpoint queue before every send and this extra call to the broker may have significant performance impact. This setting removes that extra call and is safe to use when it is known that the receiving endpoint supports delayed delivery and has already made the required declaration. Before attempting to solve this issue, we should measure the performance impact of the extra call before each send to see if it is indeed significant.
Another option is to make the call once, on the first send, and then skip the call on the next send, by recording that first call in memory.
The text was updated successfully, but these errors were encountered:
An idea how to solve it was raised during maintainer sync. We could use deadletter exchange to move all undelivered messages to the predefined queue. This queue would be consumed by every endpoint and would throw exception on that message moving it into ServiceControl error queue. That would allow for the end user to retry the message after the receiving endpoint is turned on.
This setting was removed in 4.3.1, due to #367.
In order to support legacy endpoints which do not declare the delay infrastructure, a delayed message sender declares the binding between the delay infrastructure and the receiving endpoint queue before every send and this extra call to the broker may have significant performance impact. This setting removes that extra call and is safe to use when it is known that the receiving endpoint supports delayed delivery and has already made the required declaration. Before attempting to solve this issue, we should measure the performance impact of the extra call before each send to see if it is indeed significant.
Another option is to make the call once, on the first send, and then skip the call on the next send, by recording that first call in memory.
The text was updated successfully, but these errors were encountered: