[PATCH] backend conditional requests 5th release

[Dmitry Panov]

Ok, I have reproduced the bug on the unpatched trunk (revision 
25c5f2ed3229e41e99eadff57374c3a93b41a356) without using custom vcl (the 
only section I have there is the backend specification).

Command to run varnish was:

/opt/varnish/sbin/varnishd \
     -a 0.0.0.0:6802 \
     -f /opt/varnish/etc/varnish/my.vcl \
     -P /var/run/varnishd.pid \
     -T 127.0.0.1:2000 \
     -d \
     -s file,/opt/varnish/var/varnish/storage.bin,1G

The system is running Debian with 32 bit kernel. As I mentioned earlier 
I was able to reproduce the problem on another machine with 
significantly different hardware configuration. The only common thing 
was that they were running debian with 32bit kernel. Also I used the 
same binaries on both machines. I could not reproduce the problem in 64 
bit environment.

I'm attaching the stack trace and the log file. Please let me know if I 
can provide any more info.

On 09/03/2011 14:51, Geoff Simmons wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 03/ 9/11 03:17 PM, Dmitry Panov wrote:
>> Just a heads up, I'm getting assertion failures when running a rather
>> simple testcase: using local apache that serves /user/share/doc as the
>> backend and running wget -r http://localhost:6802/doc Shortly after that
>> the following errors start to appear:
>>
>> Child (11125) Panic message: Assert error in http_Write(), cache_http.c
>> line 1181:
>>    Condition((hp->hd[HTTP_HDR_STATUS].b) != 0) not true.
>> thread = (cache-worker)
> Thanks for the heads up. Can you send over the whole stack trace?
>
>> I have been able to reproduce it on 2 different machines with very
>> different hardware configurations which makes hardware problem quite
>> unlikely. Also
>>
>> httperf --server localhost --port 6802 --uri /  --num-conns 1
>> --num-calls 4000
>>
>> runs without a problem.
>>
>> These 2 machines both run 32bit linux kernel. I haven't been able to
>> reproduce the problem in a 64bit environment.
> Could be running out of workspace. I fixed a similar error during the
> course of development, which had to do with the fact that sufficient
> workspace has to be allocated for the both backend response *and* the
> stale object; you might have found something related. Also, I've only
> been testing with 64 bit; looks like I better test 32 bit as well.
>
> Is there any way you can send the request&  response that are being
> processed when the error happens?
>
> And what if you set --num-conns high and --num-calls low, say 400
> connections and 10 calls per connection? Or keep setting --num-conns
> higher, to see if you can provoke the error? I've been running httperf
> with 25,000 connections and 1000 calls per connection, found a memory
> leak that way.
>
>> Unfortunately I haven't got time to try the unpatched trunk (I tried it
>> with revisions 3 and 4 of the patch) or do any further experiments but
>> I'll try to do so in the next couple of days and then post more details.
> It's a good idea to test on the unpatched trunk as well, to make sure
> that the bug really comes from the patch.
>
> Thanks very much for the feedback!
>
>

Best regards,

-- 
Dmitry Panov

-------------- next part --------------
A non-text attachment was scrubbed...
Name: logfile.txt.gz
Type: application/x-gzip
Size: 12618 bytes
Desc: not available
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20110309/ac23deb9/attachment-0003.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: trace.txt
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20110309/ac23deb9/attachment-0003.txt>