BIND 10 #2244: remove ddns component, but boss still keeps trying to start it

[BIND 10 Development]

#2244: remove ddns component, but boss still keeps trying to start it
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:  jinmei
                       Type:         |                Status:  reviewing
  defect                             |             Milestone:
                   Priority:         |  Sprint-20121009
  medium                             |            Resolution:
                  Component:  Boss   |             Sensitive:  0
  of BIND                            |           Sub-Project:  Core
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:7 vorner]:

 > Did you try running the system tests? It seems to be failing reliably
 for me, like this:

 I'm pretty sure I did lettuce tests and confirmed they passed (I
 reconfirmed it now); I must confess I probably skipped the older
 system tests, but I suspect the failure you've seen is due to
 something else.

 Actually, I can see that happen too sometimes (not always
 reproducible), but the same thing happens (again, sometimes) on the
 master branch too.  On a closer look into the log file when it fails,
 I noticed b10-auth received queries before it fully started up.
 I suspect, depending on the timing, when b10-auth tries to receive
 config message from cfgmgr in the initialization phase it can actually
 accept and handle query via SessionImpl::readData()
 (io_service().run_one() would invoke an incorrect event).  This is not
 good, and I guess we need to address this in a cleaner way, but that's
 certainly outside of the scope of the ticket.

 I'm not sure whether this branch can specifically introduce
 regressions in system tests.  If you see the failure selectively on
 this branch, we should probably discuss it more.  If it happens on
 master or 93e596c (the branch point) too, that should be a different
 matter (we should probably create a ticket for that).

 > And there are the minor things. The log description is missing „m“ at
 the end of the line:
 > {{{
 > The boss module simply skipped restarting that module, and the whole
 syste
 > went back to the expected state (except that the crash itself is likely
 > }}}

 Good catch, thanks.  Fixed.

 > The method name `is_failed` looks like wrong in English. I know it is
 because of consistency, but it would look more correct as `has_failed` or
 `is_restarting`.

 Okay, I've changed it is_running() so that both are consistently named
 is_xxx().

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