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
Received on Wed Sep 25 2013 - 14:31:55 MDT
This archive was generated by hypermail 2.2.0 : Wed Sep 25 2013 - 12:00:06 MDT