These are chat archives for akkadotnet/akka.net
UnconfirmedWarningmessage to itself if some message cannot be delivered for some reason.
@Horusiath Thanks, I'm aware of that setting. Maybe I miss something but as far as I understand the current implementation it's not possible to prevent "overflooding" the "target" of an at least once delivery actor.
Assume we have an at least once delivery actor which forwards messages to a remote actor of another actor system.
We have a constant message rate produced from the at least once delivery actor.
The target actor will initiate some actions based on it's received messages which may slow down it's message acceptance / confirmation rate.
If it's message acceptance rate gets very slow the at least once delivery actor continues sending with it's original message rate and on top of that all message which have not been
confirmed (because of slowed down message acceptance / confirmation rate of the target actor) will be sent again.
This means the message rate from the at least once delivery actor will increase and the load on the target actor increases as well.
These are my observations, so I'd be interested about your thoughts or if I miss something here...
@Sam13 what you're talking about seems to be more the problem of how are you handling the messages - in most of the standard cases there should never be a need to send the message more than once. This should happen only if message was lost due to network split or machine crash. Otherwise you should think about relaxing redelivery interval or parallelizing the work.
Also if your computations are expensive (hence there's any risk of not emitting confirmation on time), try to think about some mechanism for deduplication - so that, when the message that was processed before is received twice or more times, it won't be processed again and again. Instead if it was handled once, respond with confirmation right away.
: base(@"akka.loglevel = DEBUG")to the test class, then it passes