improve robustness

[qzhuyan]

No description provided.

[qzhuyan]

overall, it looks like this

v5.3.1-alpha.1-g42fa1289([email protected])34> esockd:listeners().
[{{'tcp:default',{{0,0,0,0},1883}},<0.2626.0>},
 {{'ssl:default',{{0,0,0,0},8883}},<0.2606.0>}]
v5.3.1-alpha.1-g42fa1289([email protected])35> supervisor:which_children( <0.2626.0>).
[{listener,<0.2629.0>,worker,[esockd_listener]},
 {acceptor_sup,<0.2628.0>,supervisor,[esockd_acceptor_sup]},
 {connection_sup,<0.2627.0>,supervisor,
                 [esockd_connection_sup]}]

[qzhuyan]

remove it because I don't want to spread errors to the entire sup tree.

[zmstone]

econnaborted - Software caused connection abort

econnaborted is maybe an error happens while socket is being closed.

• If it's an transient error, it could be retried, e.g. Fix issue#27 - {accept_error,econnaborted} crasher #28 thought it's transient.
• If it's an permeant error, maybe the best strategy is to:
  • close the socket, and stop with normal reason
  • socket close will trigger listener process to restart, which will in turn restart acceptors due to rest_for_one

If we cannot bet on retry, then close socket + stop normal is perhaps a better choice.

[zmstone]

This comment provided some hint on the cause:
https://github.com/erlyaws/yaws/blob/5c472e945f7310d76bb95cd949d54fd06a35158b/src/yaws_server.erl#L1124-L1127

It seems people treat econnaborted as transient error:
e.g.
https://github.com/hukl/elli/blob/db4c021e7ef7a1a8179a3f522601af45301b267e/src/elli_http.erl#L30-L31
https://github.com/benoitc-attic/barrel_tcp/blob/e689d0f4286b97462e0fda455f87501dc0ef4487/src/barrel_acceptor.erl#L58-L60
can find more from this search:
https://github.com/search?q=econnaborted+language%3AErlang&type=code

[zmstone]

close the socket before stop ?
so the listener process will for sure get an EXIT signal

[qzhuyan]

just record after discussion:
We don't need to close the listen port here to avoid spreading the error to the other acceptors (where other acceptors will get closed error) since we don't know if the error is from the Listen port or some other unknown posix errors.
AND we have a listener process that handles the EXIT signal from the listen port.
AND we trust OTP will trigger port signals if listen port is unusable, unacceptable.
AND we checked that inet_tcp:accept does not close the port when it gets an error, thus we follow it.