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