Be able to distinguish between deliberate stops and socket failures.
archseer opened this issue · 4 comments
One of the main issues we have is that if the ESME's socket fails, we will shutdown as {:stop, :normal, state}, which looks the same as if we just regularly stopped the ESME. We need to be able to distinguish between a closed socket (network failure, restart the process), and the application trying to stop the ESME.
Hello!
There are already two callbacks in SMPPEX.SMPPHandler protocol: handle_socket_closed and handle_socket_error, but they are stubbed in ESME SMPPHandler implementation till someone really needs them.
So now I am going to add them to SMPPEX.ESME and SMPPEX.MC behaviour and call them when the corresponding events happen.
Okay! if that gives us the chance to modify the exit value, then that works for us (the problem we had with {:stop, :normal, state} was in combination with supervising the process as :transient, then that would count as a regular shutdown and the process wouldn't restart)
Hello!
I have made some updates in the branch https://github.com/savonarola/smppex/commits/issue-17-socket-failures-custom-exit
Now the handle_stop callback additionally receives
- stop reason, they are listed in https://github.com/savonarola/smppex/blob/issue-17-socket-failures-custom-exit/lib/smppex/esme.ex#L129
- lost pdus — pdus, which were sent, but which have not received resps. These PDUs are mentioned in https://github.com/savonarola/smppex/issues/18
The callback now should return tuple {exit_reason, new_state}.
Dealing with old handle_stop callback is supported, but deprecation warning is issued.
Seems to be resolved by https://github.com/savonarola/smppex/pull/21