[erlang-questions] Message delivery in case of process restart

[yas...@gmail.com]

Hi,

If a process crashes and is restarted by the supervisor, what happens to the messages that were sent to the process after it crashed and before it restarted? Are they collected and stored somewhere and are they sent to the process when it is ready to receive?

Thanks,
Yash

[Gleb Peregud]

They are lost. New instance of this process will have new Pid. There are no built-in store-and-forward features in Erlang, but they can be implemented by a proxy process. But I never had a need to do that in all of my projects. What is your use case?

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Vance Shipley]

On Fri, May 17, 2013 at 06:17:54AM +0000, yas...@gmail.com wrote:
} If a process crashes and is restarted by the supervisor, what
} happens to the messages that were sent to the process after it
} crashed and before it restarted?

http://www.erlang.org/doc/reference_manual/expressions.html#send

"Sending a message to a pid never fails, even if the pid
identifies a non-existing process."

} Are they collected and stored somewhere and are they sent to the
} process when it is ready to receive?

No.

--
-Vance

[Jonathan Schneider]

> "Sending a message to a pid never fails, even if the pid
> identifies a non-existing process."
>

The documentation could be clearer. It means never causes an error for the sender.

Jon

[Joe Armstrong]

On Fri, May 17, 2013 at 11:09 AM, Jonathan Schneider <j...@axismilton.ltd.uk> wrote:

>   "Sending a message to a pid never fails, even if the pid
>    identifies a non-existing process."
>

The documentation could be clearer. It means never causes an error for the sender.

Yes - *sending* messages always works if you have a valid Pid. This does not mean that
*receiving* the message succeeds.

Suppose the Pid refers to a process on a remote machine. When you send the message the
remote process might exist. But the remote machine might die while the message is in transit
between the machines.

Failure of a remote process can be detected by linking to the process. If the process you have linked to
dies you'll be send an exit signal.

Receiving a message is a somewhat vague idea. When you send a message to a process
it gets put in the mailbox of the receiving processes (assuming the receiving process has not died).

The word "receiving" might mean "put in the receives mailbox" or "evaluates one of the receive
clauses in a receive statement."

If you want to really know that a message was received and acted upon, you need to send a confirmation
message back the the sender, when you get this message you'll know that the message was
processed by the receiver. If you also link to the process you'll get an error signal back if the process fails.

So basically you link to the remote process, send it a message and you'll either get a reply
or an exit signal back.

Cheers

/Joe