Problem: complexity associated with error handling #32
Conversation
Currently, bridge will try to handle errors in some way in order to attempt to restore its functionality. However, this limits as to how the errors can be handled as every time a change in handling is needed, a patch for bridge will needed. Overtime, this will inevitably grow into a full-fledged supervisor. However, there are already supervisor programs out there (starting from all-encompassing systemd down to small supervision utilities) Solution: revert the handling of errors to the old behaviour but (very importantly) make bridge return meaningful error codes for all known error types so that the supervisor can make a proper decision as to what has to be done (restart, delayed restart, permanent shutdown, notification, etc.)
ghost
assigned 
|
Does it mean that Linux is only the system where bridge can be run? We opened the issue #22 which caused the changes you are going to rollback just after observations in development environment. Just would like to understand what is the scenario for development environment. |
|
Oh, absolutely not limited to Linux. Any kind of shell script, PowerShell, dedicated supervisor would do the job. The intention for the development environment is to provide a simple shell script that'll do simple restarts (it'll be immediately more flexible for its users as you'd just need to alter the script to do different things depending on the error code if you need to) |
|
Since you are rolling back the changes as so the bridge will start relying on a third party tool, could you provide an example of such shell script in order to other developers (e.g. me and Roman) could use it in tests? |
It is impossible to tell whether the bridge is being shut down intentionally or because of an error. This is particularly important for supervising the process, both in development and production. Solution: handle SIGINT and SIGTERM as a special case and designate a separate status code (3) for intentional shutdowns. Also, include an example supervisor for development mode (examples/suprevisor). Simply prepend it before the invocation of bridge to supervise it.
|
Oh yes, of course. I just amended this PR to include such a script, as well as handle "intentional" shutdowns. |
Problem: complexity associated with error handling
Currently, bridge will try to handle errors in some
way in order to attempt to restore its functionality.
However, this limits as to how the errors can be handled
as every time a change in handling is needed, a patch
for bridge will needed.
Overtime, this will inevitably grow into a full-fledged
supervisor.
However, there are already supervisor programs out there
(starting from all-encompassing systemd down to small
supervision utilities)
Solution: revert the handling of errors to the old behaviour
but (very importantly) make bridge return meaningful error
codes for all known error types so that the supervisor
can make a proper decision as to what has to be done
(restart, delayed restart, permanent shutdown, notification,
etc.)