BIND 10 #1543: the socket requestor should abort itself on unexpected errors

[BIND 10 Development]

#1543: the socket requestor should abort itself on unexpected errors
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  blocker       |                    Milestone:  Next-
           Component:  Boss of BIND  |  Sprint-Proposed
           Sensitive:  0             |                     Keywords:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |  Socket creator
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 Currently (as of #1522) the socket creator just throws an exception
 in the arguably rare event of encountering unexpected failures in the
 communication with the boss process (either via the msgq bus or the
 UNIX domain socket).  It's up to the application how to react to it,
 but the current client code (as of #805) doesn't do anything and keep
 using the creator.  This is probably not a good choice, because if
 such an error even happens it's more likely that something fundamental
 is broken in the msgq or the UNIX domain socket (and internal state of
 both or either of the requestor and boss), and it's more likely that
 the requestor cannot get any useful result any more.

 One possible option is to destroy the requestor and create it again,
 but doing so has a harsh side effect of clearing all sockets (in the
 boss, which will then cause inconsistency between the boss and the
 application unless the application also closes the sockets).  Even if
 we accept the side effect, the recovery process would be complicated.

 So the suggestion in the mean time is to have the requestor abort the
 program either via assert() failure or throwing a fatal exception
 (which would only be catchable at the top level of application and
 make the process terminate, possibly with logging the fact).  Assuming
 it should actually very rare, we won't see this in practice, and by
 adding the explicit handling we can be sure that we don't leave the
 code in some undefined state that just happens to cause visible
 failure by (un)luck.

-- 
Ticket URL: <https://bind10.isc.org/ticket/1543>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development