BIND 10 #2636: stats crash

BIND 10 Development do-not-reply at isc.org
Fri Jan 18 15:00:27 UTC 2013


#2636: stats crash
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  medium        |                    Milestone:  New
           Component:  statistics    |  Tasks
            Keywords:                |                   Resolution:
           Sensitive:  0             |                 CVSS Scoring:
         Sub-Project:  Core          |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by vorner):

 Hello

 Replying to [comment:2 shane]:
 > Surely the cc library should retry on timeout?

 Surely not. The msgq does not lose messages. So if there was a recipient,
 the request got delivered. If there wasn't, there wouldn't be at the time
 of retry as well, so it would be a waste.

 If there is the recipient, either the handling takes a long time (and
 doing it once again would probably take a long time too, timeouting again,
 and burning CPU), or the recipient just doesn't want to answer.

 So the retry doesn't help either of the cases. And, it could make it worse
 ‒ imagine the message had some sideeffect, like increasing the number of
 running auth processes by one (by design, not by accident). Then
 delivering it twice is not what the administrator asked for.

 It could be solved by setting a longer timeout, but before we do so, we
 need to make sure the timeouts don't happen in normal circumstances, eg.
 when the recipient isn't there.

 > Also, is whatever process was using all the memory gone now? (It would
 be nice to know where the problem came from, of course!)

 Could be something outside bind10 as well. Is there some kind of backup,
 or something?

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


More information about the bind10-tickets mailing list