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