Sorry for not being for specific.
The initial backend being set is the one that is always used no matter what the
URL.
So, when I come in with a URL of /syscheck/blah.htm, I would expect the
alternative backend to be used. It does not get select, and instead the
original one is the one used, and therefore I end up with either a HTTP 404 or
a HTTP 503, depending on the mood of Drupal the destination of the initial
backend.
Thanks!
A J Drew
Here is some output from varnishlog of a call:
2 Begin c req 1 rxreq
2 Timestamp c Start: 1474629889.600227 0.000000 0.000000
2 Timestamp c Req: 1474629889.600227 0.000000 0.000000
2 ReqStart c 127.0.0.1 34608
2 ReqMethod c GET
2 ReqURL c /syscheck/wwwul2370.htm
2 ReqProtocol c HTTP/1.1
2 ReqHeader c Host: xxxxxx.example.com
2 ReqHeader c Accept: text/html, application/xhtml+xml, */*
2 ReqHeader c Accept-Language: en-US
2 ReqHeader c User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
Trident/7.0; rv:11.0) like Gecko
2 ReqHeader c Accept-Encoding: gzip, deflate
2 ReqHeader c Cookie: ObSSOCookie=loggedout;
TLTSID=A5D86DBA4DA97DFA943BD59DA9EFF5B8;
dtCookie=3A7E953F591088FA2F6DB23E157B3A54|Q1NTX19FQV9fYXV0aG9yaXphdGlvbi1oYW5kbGVyLWVhcnwxfENTU19fRUFfX2FjY291bnQtYWdncmVnYXRpb24tZWFyfDE;
dtLatC=36971; dtPC=-; RANDOM_ID=6529725af06
2 ReqHeader c Via: 1.1 xxxxxx.example.com
2 ReqHeader c X-Forwarded-For: 172.22.159.116
2 ReqHeader c X-Forwarded-Host: xxxxxx.example.com
2 ReqHeader c X-Forwarded-Server: xxxxxx.example.com
2 ReqHeader c Connection: Keep-Alive
2 ReqUnset c X-Forwarded-For: 172.22.159.116
2 ReqHeader c X-Forwarded-For: 172.22.159.116, 127.0.0.1
2 VCL_call c RECV
2 VCL_return c pass
2 VCL_call c HASH
2 VCL_return c lookup
2 VCL_call c PASS
2 VCL_return c fetch
2 Link c bereq 3 pass
2 Timestamp c Fetch: 1474629891.152683 1.552456 1.552456
2 RespProtocol c HTTP/1.1
2 RespStatus c 404
2 RespReason c Not Found
2 RespHeader c Date: Fri, 23 Sep 2016 11:24:49 GMT
2 RespHeader c Server: Apache
2 RespHeader c X-Drupal-Cache: MISS
2 RespHeader c Expires: Sun, 19 Nov 1978 05:00:00 GMT
2 RespHeader c Cache-Control: public, max-age=3600
2 RespHeader c Content-Language: en
2 RespHeader c X-Generator: Drupal 7 (http://drupal.org)
2 RespHeader c Etag: "1474629889-0"
2 RespHeader c Last-Modified: Fri, 23 Sep 2016 11:24:49 GMT
2 RespHeader c Vary: Cookie,Accept-Encoding
2 RespHeader c Strict-Transport-Security: max-age=31536000;
includeSubDomains; preload
2 RespHeader c X-XSS-Protection: 1;
2 RespHeader c Content-Type: text/html; charset=utf-8
2 RespHeader c X-Varnish: 2
2 RespHeader c Age: 0
2 RespHeader c Via: 1.1 varnish-v4
2 VCL_call c DELIVER
2 RespHeader c X-Cache: MISS
2 RespUnset c Via: 1.1 varnish-v4
2 RespUnset c X-Generator: Drupal 7 (http://drupal.org)
2 RespUnset c Server: Apache
2 VCL_return c deliver
2 Timestamp c Process: 1474629891.152737 1.552510 0.000054
2 RespHeader c Content-Length: 7685
2 Debug c "RES_MODE 2"
2 RespHeader c Connection: keep-alive
2 Timestamp c Resp: 1474629891.152783 1.552556 0.000046
2 ReqAcct c 791 0 791 500 7685 8185
2 End c
From: Guillaume Quintard [mailto:[email protected]]
Sent: Friday, September 23, 2016 8:12 AM
To: Drew, AJ
Cc: [email protected]
Subject: Re: Problem Upgrade to Varnish 4.1 - Multiple Backends Not Working
What does "stop working" mean? Does the vcl fail to compile? do you receive
503s? does it open a portal to an ancient dimension filled with unspoken
nightmares? Help us help you.
--
Guillaume Quintard
On Fri, Sep 23, 2016 at 1:52 PM, Drew, AJ
<[email protected]<mailto:[email protected]>> wrote:
Hello,
We are trying to upgrade to Varnish 4.1 from Varnish 3.0.5.
Most things are working fine, but a big problem we are running into is that we
have multiple backends. We switch backends based on URLs. This was working
fine in Varnish 3, but when we switched over to Varnish 4, it stopped working.
I have tried many variations of the URLs, and even simplified the directors so
that they only contain one backend (in my tests) so that I could switch from
trying the backend directly to trying the director.
Using either of the options does not seem to matter.
Has anyone else run into this problem?
Here are the sections of my VCL that contain the backends / director
definitions and the if statements to switch. I have also left in the different
options (lines) I have used to come up with different combinations for testing.
probe B_probe {
.request =
"GET /zzzzzz/status.php HTTP/1.1"
"HOST: xxxxxx.example.com<http://xxxxxx.example.com>"
"Connection: close";
.timeout = 0.3 s;
.window = 8;
.threshold = 7;
}
backend B_backend1 {
.host = "162.131.196.220";
.port = "8080";
.probe = B_probe;
}
backend syscheck {
# .host = "localhost";
.host = "127.0.0.1";
.port = "8081";
}
backend searchBackend {
.host = "rp.www.example.com<http://rp.www.example.com>";
.port = "80";
}
backend providerBackend {
.host = "172.23.82.28";
.port = "80";
}
sub vcl_init {
new examplehosts = directors.round_robin();
examplehosts.add_backend(B_backend1);
new examplesyscheck = directors.round_robin();
examplesyscheck.add_backend(syscheck);
}
sub vcl_recv {
# set req.backend_hint = examplehosts.backend();
set req.backend_hint = B_backend1;
if (req.url ~ "^/syscheck/.*$") {
# if (req.url ~ "^/syscheck/*") {
# if (req.url ~ "^/syscheck/") {
set req.backend_hint = syscheck;
# set req.backend_hint = examplesyscheck.backend();
return(pass);
}
# Add simple health check for upstream load balancers
if (req.url ~ "^/health-check") {
return( synth(200, "UP"));
}
...
Thanks!
A J Drew
-----Message Disclaimer-----
This e-mail message is intended only for the use of the individual or entity to
which it is addressed, and may contain information that is privileged,
confidential and exempt from disclosure under applicable law. If you are not
the intended recipient, any dissemination, distribution or copying of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by reply email to
[email protected]<mailto:[email protected]> and delete or destroy all
copies of the original message and attachments thereto. Email sent to or from
the Principal Financial Group or any of its member companies may be retained as
required by law or regulation.
Nothing in this message is intended to constitute an Electronic signature for
purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic
Signatures in Global and National Commerce Act ("E-Sign") unless a specific
statement to the contrary is included in this message.
If you no longer wish to receive any further solicitation from the Principal
Financial Group you may unsubscribe at
https://www.principal.com/do-not-contact-form any time.
If you are a Canadian resident and no longer wish to receive commercial
electronic messages you may unsubscribe at
https://www.principal.com/do-not-email-request-canadian-residents any time.
_______________________________________________
varnish-misc mailing list
[email protected]<mailto:[email protected]>
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
_______________________________________________
varnish-misc mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
