BIND 10 #1429: Commands for sockets

BIND 10 Development do-not-reply at isc.org
Wed Dec 7 15:13:57 UTC 2011


#1429: Commands for sockets
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111220
                  Component:  Boss   |            Resolution:
  of BIND                            |             Sensitive:  0
                   Keywords:         |           Sub-Project:  Core
            Defect Severity:  N/A    |  Estimated Difficulty:  0
Feature Depending on Ticket:         |           Total Hours:  0
  Socket creator                     |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:10 jinmei]:
 > - BIND10_LOST_SOCKET_CONSUMER doesn't include the parameter in the
 >   message description, resulting in:
 > {{{
 > BIND10_LOST_SOCKET_CONSUMER consumer of sockets disconnected,
 considering all its sockets closed @@Missing placeholder %1 for '42'@@
 > }}}
 >   (If you normally don't do this) I suggest trying to have the program
 >   print newly added log message by 'B10_LOGGER_DESTINATION=stdout make
 >   check | grep <msg_id>'.  This is my usual practice when I add a new
 >   log ID.

 I often am too lazy to do so, as I need to read the documentation of the
 logging system to know what the correct name of the environment variable
 is :-|. I'll have to write a script to do it for me.

 > - As for the description of BIND10_LOST_SOCKET_CONSUMER, if the
 >   applications are generally expected to gently release the requested
 >   sockets before shutting down themselves, I'd clarify that
 >   "terminated" is something like unexpected crash or something.

 Well, it doesn't have to crash. Even if it returns all the sockets
 correctly, it still needs to close the unix-domain socket and the boss
 doesn't distinguish the difference. Maybe it could, but I prefer not to as
 it doesn't seem to bring anything important functionality-wise.

 > > > - socket_consumer_dead()
 > > >   - is it okay not to catch exceptions?
 > >
 > > Ups, you're right. It's maybe even worse than you thought, as the
 exception can happen in normal operation and is perfectly OK. Added.
 >
 > Okay, but is it okay to only catch ValueError?

 The function is not supposed to raise anything else. It should be simple
 enough and touches only local data. So, if it raises anything else, it is
 either a programming error or something really nasty, like out-of-memory.
 I think it is best to just let it go through and boss to terminate.

 > I meant this one:
 > {{{#!python
 >         bob._get_socket = get_socket
 >         args = {
 >             "port": 53,
 >             "address": "0.0.0.0",
 >             "protocol": "UDP",
 >             "share_mode": "ANY",
 >             "share_name": "app"
 >         }
 >         # Test it just returns whatever it got. The real function
 doesn't
 >         # work like this, but we don't want the command_handler to touch
 it
 >         # at all and this is the easiest way to check.
 >         self.assertEqual({'result': [0, args]},
 >                          bob.command_handler("get_socket", args))
 > }}}
 >
 > And, recognizing you changed the IPv4 address used in
 > TestCacheCommands to an IPv6 address, what I would have suggested is
 > something like an attached diff.

 That slightly changes the semantics of the test, but I don't oppose. I
 cleaned it a little bit.

 Thanks

-- 
Ticket URL: <http://bind10.isc.org/ticket/1429#comment:12>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list