BIND 10 #1924: Msgq undeliverable notifications

[BIND 10 Development]

#1924: Msgq undeliverable notifications
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  msgq          |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130219
         Sub-Project:  Core          |                   Resolution:
Estimated Difficulty:  6             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:  msgq-
                                     |  ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:15 jinmei]:
 > I suggest you remove your local trac1914 branch to avoid further such
 > confusion.

 Sorry. I installed a new computer in between and I unpacked an older
 backup of my home there, which still had the wrong branch. It's fixed on
 this new computer now too, so it should be OK I hope.

 Replying to [comment:17 jinmei]:
 > In that case I believe it should be "the senders that hunger for
 > response".

 I meant hunger as noun, not a verb. But I changed the whole thing anyway,
 so it should be clearer.

 > - isc::util doesn't seem to be an appropriate place to define them.
 >   "CC" is specific to the cc module, while util is generally expected
 >   to be (kitchensink) placeholder for things that don't belong to
 >   anything else.  It's as awkward as seeing e.g. b10-auth log message
 >   IDs are defined in isc::util.

 I'm not sure. I thought the file could be used for other constants too, in
 future. Like some protocols between auth and XFROUT and such. Or do you
 think it is better to have separate constants file for each of these? Then
 we need to put the generator scripts somewhere common, though, and I'm not
 sure where.

 > - I'm not so sure if handling partial send failure (there are multiple
 >   possible recipients and a subset of them fail) as an "OK" case; if
 >   xfrin sends something to multiple instances of auth and not all of
 >   them were correctly delivered (but the failing auth is still somehow
 >   running), the system will be in an inconsistent state.  That said,
 >   this level of discussion is probably beyond the scope of this ticket
 >   and should go to the larger msgq revisit work.  So I'm making it
 >   just as a comment, not a request for changing the code.

 This is not about consistency. This is about the fact that when one
 process wants to call a remote function to get some information, it needs
 to wait for an answer. This is to provide an answer that no real data will
 ever come. Generally, the expected number of recipients would be one. Even
 if there are more and one of them is not receiving, the others will
 provide answer, so this is correct. The parameter is not called
 „must_deliver_to_all“, but „want_answer“.

 Also, what you describe is probably a notification that does not need any
 kind of answer at all anyway.

 And, finally, if there was EPIPE or something from the recipient, it means
 it is probably already dead. If it isn't, it will be soon, because our
 modules can't live without the CC connections and if they lose it, they
 usually just crash (and get restarted).

 So, from these points, I believe the current behaviour is the more correct
 one.

 > - unrelated, but noticed: the return type of group_sendmsg seems to be
 >   wrong: it returns a `long int` value but the type is `int`; often
 >   the latter is small in size and would cause overflow.

 I added this to the #2674 ticket, since it's related. I don't want to hunt
 down all occurrences of group_sendmsg to check the type is changed on the
 caller side too.

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