BIND 10 #3075: Implement Main Event Loop in D2Process

[BIND 10 Development]

#3075: Implement Main Event Loop in D2Process
-------------------------------------+-------------------------------------
            Reporter:  tmark         |                        Owner:  tmark
                Type:  enhancement   |                       Status:
            Priority:  medium        |  assigned
           Component:  dhcp-ddns     |                    Milestone:  New
            Keywords:  Task# 6.2.1   |  Tasks
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DHCP          |                 CVSS Scoring:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by tmark):

 With git c39eb9bbe30285a2b19fea86473b63ddb758506b:

 The main event processing loop has been added to D2Process.  This loop is
 runs
 in the main application thread until the process is shutdown. The initial
 design
 for DHCP_DDNS placed this loop within the Update Manager class but during
 pre-implementation analysis it become evident that it belonged at a
 higher,
 architectural level.

 This loop is responsible for:
 1. Ensuring that the IO service(s) are given time to perform IO and invoke
 callbacks
 2. Monitoring and  managing the Queue manager's state
 3. Ganting time to the Update Manager to monitor transactions in progress
 and
 create new transactions by dequeuing requests from the queue

 During this work a shortcoming in the process of stopping an active
 listener
  was uncovered which forced some modifications to NameChangeListener
 classes
 in dhcp_ddns and to an expansion of the D2QueueManager's state model. In
 short,
 the original design/implementation assumed that moving from a state of
 actively
 listening to not listening was a synchronous process.  This premise turns
 out
 not to be true in all cases.  In the event that the listener has begun an
 asynchronous read, that read will be aborted by a cancel() or close() on
 the
 listener's socket.  This in turn generates an invocation of the callbaçk
 registered with the asynchronous read, with a error code indicating
 operation
 aborted.   It is important for the application to expect and wait for this
 callback to be invoked, prior to taking any further action such as
 destructing
 any of the classes associated with the callback.

 To address this situation, the NameChangeListener class was modified to
 know
 if there is a read pending, and the D2QueueManager's state model now
 includes
 a new state of STOPPING.  When the queue manager attempts to stop
 listening, it
 will only transition to a stopped state (there are three possible stop
 states)
 once the listener has no outstanding IO.  In other words, if the listener
 has
 not issues a read, than the stopped state is reached immediately.  If,
 however
 the listener has an pending read, the state remains STOPPING until the
 read
 completes whether by incoming packet, error, or by "operation aborted".
 The
 latter of which by far the most likely.

 In addition to adding the event loop, the shutdown command for b10-dhcp-
 ddns
 was expanded to accept an argument for the type of shutdown to be
 performed.
 There are currently three shutdown types:

 SD_NORMAL - stops receiving new requests immediately, but does not exit
 until
 all current transactions are completed.

 SD_DRAIN_FIRST - stops receiving new requests immediately, but does not
 exit
 until all of the currently queued requests have been processed.

 SD_NOW - stop immediately, any current transactions will be abandoned.

 And of course, there were several new logging messages added.

 Fixed a small bug in configuration management, that went undetected until
 now.
 Parsing two configurations in a row containing or more of the same TSIG
 keys
 was failing on a "duplicate key" error. Unlike the other list parsers, the
  TSIG list parsing was working directly with the context's map of keys
 rather
 than a local list.  Since the context is not wiped before each
 configuration,
 the keys were colliding.

 A break down of the changes per file follows:
 {{{
 Changes related to duplicate TSIGKeyInfo error when parsing subsequent
 configurations:
 #       modified:   src/bin/d2/d2_config.cc
 #       modified:   src/bin/d2/d2_config.h
 #       modified:   src/bin/d2/tests/d2_cfg_mgr_unittests.cc

 Several new messages:
 #       modified:   src/bin/d2/d2_messages.mes

 Implemented event loop processing, most new code here:
 #       modified:   src/bin/d2/d2_process.cc
 #       modified:   src/bin/d2/d2_process.h

 Modified state model to support state of STOPPING. Handles the fact that
 stopping IO is asynchronous and you may have to wait for cancel to avoid
 dangling callbacks.
 #       modified:   src/bin/d2/d2_queue_mgr.cc
 #       modified:   src/bin/d2/d2_queue_mgr.h
 #       modified:   src/bin/d2/tests/d2_queue_mgr_unittests.cc

 Adding support for shutdown with arguments.
 #       modified:   src/bin/d2/d_controller.cc
 #       modified:   src/bin/d2/d_controller.h
 #       modified:   src/bin/d2/d_process.h
 #       modified:   src/bin/d2/dhcp-ddns.spec

 Lots of new tests for event loop logic.
 #       modified:   src/bin/d2/tests/d2_process_unittests.cc
 #       modified:   src/bin/d2/tests/d_test_stubs.cc
 #       modified:   src/bin/d2/tests/d_test_stubs.h

 Changes primarily to listener to support knowing when a read is in
 progress
 and will generate an event if canceled.
 #       modified:   src/lib/dhcp_ddns/dhcp_ddns_messages.mes
 #       modified:   src/lib/dhcp_ddns/ncr_io.cc
 #       modified:   src/lib/dhcp_ddns/ncr_io.h
 #       modified:   src/lib/dhcp_ddns/ncr_udp.cc
 #       modified:   src/lib/dhcp_ddns/tests/ncr_udp_unittests.cc
 }}}


 I apologize for this ticket covering a fair amount of ground but there
 were not many good places to split it up.  It does not contain all that
 much new code and there are no new classes.

-- 
Ticket URL: <https://bind10.isc.org/ticket/3075#comment:2>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development