Delay pools locks up subsequent connections

Dear all,

I am experiencing weird behaviour with delay_pools.
Using Squid versions 2.2.STABLE3 or 2.2.STABLE4-hno.19990804 under Linux
2.2.10-ac8, my HTTP transfers are never concurrent. To be more precise,
when I start to retrieve an URL B while an other object (URL A) is
currently being fetched, URL B data start to arrive ONLY when URL A
retrieval is over.
(both transferts take place via the proxy of course, and originate from
the same client, and are always retrieved from the source, not the
cache).

It seem to me that the first URL that is retrieved through the proxy is
eating
all the client allowed bandwith starving the other connections.

Here is my delay pools config. The test client is in INTERNAL

   delay_pools 1
   delay_class 1 3
   delay_access 1 allow INTERNAL
   delay_access 1 allow E195
   delay_access 1 allow CSLC
   delay_access 1 allow CSFA
   delay_parameters 1 16000/16000 10000/10000 4200/16000
   delay_initial_bucket_level 50

Here is a trimmed down timed tcpdump output so you can see what's
happenning :

0.000 tux.1961 > ns.domain : 12306+ (33)
0.000 ns.domain > tux.1961 : 12306* 1/1/1 (92)
0.001 tux.3672 > gate.3128 : S 1533382882:1533382882(0)
0.001 gate.3128 > tux.3672 : S 2369393775:2369393775(0) ack 1533382883
0.001 tux.3672 > gate.3128 : . ack 1
0.001 tux.3672 > gate.3128 : P 1:135(134) ack 1

[here we've done "wget
http://www.pmg.lcs.mit.edu/cgi-bin/rfc/view?1885", a quite big document]

0.001 gate.3128 > tux.3672 : . ack 135
0.456 gate.3128 > tux.3672 : P 1:171(170) ack 135

[snipped]

7.392 gate.3128 > tux.3672 : P 13299:13311(12) ack 135
7.406 tux.3672 > gate.3128 : . ack 13311
7.435 tux.1961 > ns.domain : 54877+ (33)
7.435 ns.domain > tux.1961 : 54877* 1/1/1 (92)
7.436 tux.3673 > gate.3128 : S 1556210070:1556210070(0)
7.436 gate.3128 > tux.3673 : S 2375105426:2375105426(0) ack 1556210071
7.436 tux.3673 > gate.3128 : . ack 1

[as data from the first wget is arriving on the client, we launch
another request : "wget http://slashdot.org/search.pl?topic=us", a very
small document]

7.436 tux.3673 > gate.3128 : P 1:120(119) ack 1
7.436 gate.3128 > tux.3673 : . ack 120

[request is sent to the proxy (note the client port) which acknowledges
it, but data won't come]

7.440 gate.3128 > tux.3672 : P 13311:14759(1448) ack 135
7.440 gate.3128 > tux.3672 : P 14759:14771(12) ack 135
7.456 tux.3672 > gate.3128 : . ack 14771

[snipped]

41.876 gate.3128 > tux.3672 : P 163140:164588(1448) ack 135
41.876 gate.3128 > tux.3672 : P 164588:166036(1448) ack 135
41.876 gate.3128 > tux.3672 : P 166036:167236(1200) ack 135
41.876 gate.3128 > tux.3672 : P 167236:167339(103) ack 135
41.877 tux.3672 > gate.3128 : . ack 166036
41.890 tux.3672 > gate.3128 : . ack 167339
42.876 gate.3128 > tux.3672 : P 167339:168603(1264) ack 135
42.876 gate.3128 > tux.3673 : P 1:1449(1448) ack 120

[here we start receiving data from the second request started almost 35
seconds ago]
[snipped end : connection 2 data arriving and connection 1 closing]

From this point, no more data will arrive from the first request (except
connection closing, which is ok since there is no more data to send)
which shows that
no data is sent to the client for the second request until the first
request has been completely sent to it by the proxy.
Nevertheless, watching the server-origin side connection (different
interface, not shown here) shows that data for both connection arrive
mixed at the
proxy, so this problem is not related to upstream connectivity, but
really to delay pools. And no need to say, when I turn off delay_pools,
everything is fine.
BTW, when this test is done with 2 different clients, everything is fine
too.

Any clue anyone ?
Thanks for reading, and sorry if this has been asked already, I'm having
hard time catching up with squid-users.

-- 
Michel Blanc <mblanc@erasme.org>
Centre Erasme
Parc d'activités innovantes
69930 Saint Clément-les-places
tel +33-(0)4-74-70-68-40 ext 331
fax +33-(0)4-74-70-68-41