On 25/09/2013 10:46 p.m., Eliezer Croitoru wrote:
Hey, This is indeed the issue I was aiming at.. It was never looked at before since nobody never seen this problem before If I am right. So I have a suggestion. Instead of just shooting at it we have the test "subject" in hands. The latest stable version of squid is 3.3 We can do run a basic test out of the production environment to make sure that we can reproduce the issue. Amos do we have a QA\BUG_TEST section in the bugzilla?
Not really. We tend to use the "enhancement" or "minor" importance level for both things that would be nice to get done. From what it looks like in the trace a proper fix will require someone going through the underlying network measurement logics and rearranging a few things.
This way we can look at a bug and classify it as a testing bug and close the issue with a more detailed report?? Back.. The issue is that the DNS did not responded fast enough to squid.
Not exactly. Tha debug traces provided in other email make it clear that the request is being sent during the gap where DNS response is waited for. If Squid were relying on that response in order to send the request the events would be sequential asynchronous actions instead of branching into parallel asynchronous actions.
Amos
