Supervisor protocol process cannot be stopped when connection is closed (connection_type=supervisor). about ranch

[essen]

Yes I suggested to Maria that she adds intrinsic to OTP and it became significant instead. It's a better version of it.

[essen]

I think it's because you stop the worker process with the reason normal, try shutdown or {shutdown, Reason} instead.

[ithron]

That doesn't make a difference. In my case the proto_worker is a gen_stamem and I verified that when I stop with {stop, shutdown} terminate() is called with reason shutdown. However, that has no influence on the supervisor. In the OTP supervisor documentation is says, that a supervisor is usually stopped by its parent. So shouldn't it be then the responsibility of connection_sup to terminate proto_sup or at least offer an API for it?

[essen]

You probably need to set the restart rates as well, in RabbitMQ they are 0/1 https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/rabbit/src/rabbit_connection_sup.erl#L66

You basically want to force the supervisor to stop when the process holding the socket exits. As you can see there we have a second supervisor containing other child processes which may restart independently.

[ithron]

OK, I see. RabbitMQ uses a custom supervisor implementation that adds a new worker type intrinsic that causes the supervisor to exit when the worker exits normally. When I try it with the OTP supervisor, I can get the supervisor to exit when I set the intensity to 0 and the type to permanent but that existing is reported as an error (as intended by OTP).

Is the use case of connection_type = supervisor with a OTP supervisor so rare? Shouldn't it be possible without a custom supervisor?

I've the feeling I'm still missing something here...

[essen]

I think it's the first time it comes up. I've only used it with Cowboy which has its own "supervisor" and RabbitMQ which has one of the "supervisor2" that is patched from OTP. To be honest we should probably seek to contribute this intrinsic type back to OTP. Putting it on the list. :-)

[ithron]

But what would speak against letting connection_sup stop the proto_sup on request?

[Maria-12648430]

To be honest we should probably seek to contribute this intrinsic type back to OTP.

So... a supervisor that exits when the (last) child exits? I haven't looked at RabbitMQs supervisor2, but I think that would be useful 🥰

[essen]

Yes it is indeed useful.

But what would speak against letting connection_sup stop the proto_sup on request?

If I'm understanding correctly you're asking about Ranch stopping the supervisor when the process holding the socket exits? At the moment Ranch is only aware of the supervisor, I don't think we want to make Ranch aware of more processes than it supervises directly (outside of the socket control handshake).

You can most likely have the supervisor contain a second child that would do just that, by the way, detect the connection is gone and stop the parent (the supervisor). I don't think there's a huge need to have this in Ranch.

[ithron]

Sure, but my point is, that from the pure OTP perspective, the only process than can stop a supervisor is the supervisor's supervisor, which is the connection_sup process in ranch. I don't think ranch needs to detect that the connection is gone. But only offer a function in connection_sup to stop a child, like the OTP supervisor does. Then, whatever process detects that the connection is gone can call that function of connection_sup to stop its supervisor.

It's more like the problem wouldn't exist if connection_sup would conform to OTPs supervisors (or at least offer this one function).

[essen]

I am pretty sure you can just call sys:terminate/2,3 to stop your supervisor. The thing about the parent only applies to exit signals. I do not think we need another function in Ranch for doing this.

[ithron]

AFAIK sys:terminate/2,3 will terminate the supervisor before it has the chance to gracefully stop all its child processes. This is probably OK to call in terminate/3 of the first process with an one_for_all strategy.

I tried to add a terminate_child to ranch_conns_sup but didn't found a satisfactory and clean way of doing it, so no PR from my side...

I'll probably stick to the modified supervisor method. Having the option to stop a supervisor when a specific process exists might become handy in the future.

[essen]

sys:terminate does normal termination, it's the same as if the parent was terminating it, except perhaps the terminate reason might differ.

[ithron]

OK, my fault. My worker was not set up to trap existing signals.
So maybe the sys:terminate/3 solution is the easiest one.

[rlipscombe]

w.r.t. intrinsic, OTP-24 adds the concept of "significant" children. See https://erlang.org/doc/man/supervisor.html#significant_child; I assume it's essentially the same thing.