TTL Mailbox queue

[rogeralsing]

After discussions with @DenizPiri, it would be useful to have a mailbox, that measures how long a message have been in the mailbox, and removes messages where the TTL has expired

It could be implemented with a custom mailbox queue, which contains an envelope that has a timestamp. when the mailbox pulls a message to push it into the actor, we check current time minus placed on mailbox time. if this is greater than X timespan, we send the message to deadletter instead

[marcinbudny]

What are the use cases for this functionality? I wonder if TTL mailbox covers them all.

• what if the message was sent over the network and spent some time in transit - should this time be included?
• what if the TTL should be measured as a total of all hops between multiple actors?
• what if the TTL is not measured from the moment the message is posted to the mailbox, but rather some event in the outside world (e.g. moment when a device posted the message)?
• what if the TTLed messages should go to alternative processing path instead of deadletter?

I think the users have a lot of flexibility currently to implement these scenarios with receive middleware.

[marcinbudny]

@rogeralsing @DenizPiri any input on the above questions?

[DenizPiri]

@marcinbudny I agree that the TTL mailbox wouldn't cover all the scenarios. Especially the ones you mentioned.

As for our use cases, we don't have any inter-actor communication. We usually have centric singleton actors we send requests to as a result of the client requests. So, currently, in our case, if the actor stalls for a while on a single message, let's say 10 secs, the client request side gets timed out; however, the actor has no awareness of this and continues to process the queued-up messages, which causes more lagging for the new client requests and causes those to time-out as well.

You are right, this is doable with a receive middleware. But, a simpler set-and-forget solution would be a lot more ideal I believe.

I think the core problem I am having is that actors have no built-in good mechanisms to deal with back-pressure and throttling. Our needs for a back-pressure solution are super simple, but I believe there would be clients there that would have much more complicated needs (as @marcinbudny laid out, messages hopping between multiple actors, all being a part of a single soon-to-be-timed-out request).

Maybe we can rename the title to "Mailbox Backpressure Brainstorming" and discuss more generic solutions.