I said: >> Potential Bug: In "mesh_state_cleanup", I noticed that >> "comm_point_drop_reply" is called to remove unset replies, HOWEVER, it >> does not appear that either "stats_dropped" is incremented or more >> importantly "num_reply_addrs" is not decremented. Doesn't this lack >> of a decrement potentially cause the "16 times" limit go into effect and >> prematurely drop queries?
Your response: >The num_reply_addrs is decremented when a reply is sent (which can be an >error if the mesh state is removed because of an error). The >mesh_state_cleanup indeed does not cleanup the num_reply_addrs value >correctly, but this routine is only called from the mesh_state_delete >function. Thus it does not present a bug. Okay, I agree. Consider this: Assume my Internet connection goes out for a bit, thus no replies come in, so, queries pile up quickly. Consider the following code path during this outage: mesh_new_client() -> mesh_make_new_space() -> Code in mesh_make_new_space() decides jostle is needed -> mesh_state_delete() -> mesh_state_cleanup() That causes num_reply_addrs to NOT be decremented. Now my Internet connection comes back, BUT, num_reply_addrs got so high that the "16 times" limit goes into effect. Now I get all my queries dropped even though there is no error or problem anymore. My temporary outage caused num_reply_addrs to grow and there is no way for it to come back down. So, I'm stuck dropping queries until a restart of the server. -Rob _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
