> what about [...] if a process has taken an item off a queue and then crashes before having fully processed it
> you might not even know from the outside if it has been fully, partially, or not at all processed yet
Erlang does not propose a unique solution to distributed problems, just good primitives.
So the answer would be the same; you'd keep track in the queue if the element was partially popped, but not completed, and you report back to the queue that the processing failed and that the element should be fully put back.
So in Erlang you might monitor a worker process and requeue items handled by processes that failed.
Thanks. So Erlang is really only about managing process lifetimes and simple RPC? In my experience processes often have meaningful internal state, meaningful in the sense that it matters if it gets lost due to a crash. If I understand correctly,
Erlang doesn’t provide any particular model or mechanisms for dealing with that?
Like fidotron said, a process's internal state is lost if it crashes (or exits).
If you want that state to be durable, you need to store it durably. Mnesia provides (optional) distributed transactions which may be appropriate for durability needs (lots of details). Or you could externalize durability to other systems.
Erlang is wonderful, but it's not magic. It won't prevent hardware failures, so if an Erlang process fetches something from a queue and the cpu stops for whatever reason, you've got a tricky situation. Erlang does offer a way for a process to monitor other processes, including processes on remote nodes, so your process will be notified if the other process crashes or if the other node is disconnected; but if the other node is disconnected, you don't know what happened to the other process --- maybe it's still running and there's a connectivity issue, maybe the whole host OS crashed. You could perhaps set bidirectional monitors, and then know that the remote process would be notified of the disconnection as well, if it still was running... but you wouldn't know if the process finished (sucessfully or not) after the connectivity failed but before the failure was detected and processed.
> In my experience processes often have meaningful internal state, meaningful in the sense that it matters if it gets lost due to a crash.
The erlang process state will be simply what it has on the stack. (Ignoring things like ETS tables for the moment).
Erlang has the concept of ports, used to interface to the world outside, that provide a sort of hook for cleanup in the event of a crash. Ports belong to processes, in the event of a crash all associated ports are cleaned up. You can also set this sort of thing up between purely erlang processes as well.
As the other commenter observed, erlang gives you the primitives to make distributed systems work; it does not prescribe solutions, especially around distributed transactions, which imo is one of the reasons some of the hype around the BEAM is misguided.
> you might not even know from the outside if it has been fully, partially, or not at all processed yet
Erlang does not propose a unique solution to distributed problems, just good primitives.
So the answer would be the same; you'd keep track in the queue if the element was partially popped, but not completed, and you report back to the queue that the processing failed and that the element should be fully put back.
So in Erlang you might monitor a worker process and requeue items handled by processes that failed.