Answers.Body: <p>Not really a CiviCRM issue, but in case anyone else has a similar experience.</p>
  
  <p>As Aidan correctly guessed, it was indeed due to an http/https redirect - the one that comes from CiviCRM when you tell it to use https for admin/payment pages. Which is why it was okay on some pages, and why it was spawning new php processes for each one.</p>
  
  <p>The reason this site had the problem was due to my use of a separate ssl termination ("Pound") before it went to apache. When you do this, you have to tell apache how it can know if it's been through the termination (via the use of http headers). I hadn't done that for this site, so it kept redirecting itself to the same page, not aware that it was already https.</p>
  
  <p>I put in a redirect from the http to https site, and added the required apache vhost line:</p>
  
  <pre><code>SetEnvIf X-Forwarded-Proto https HTTPS=on
  </code></pre>
  
  <p>and the issue has now been resolved.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-22T22:49:38.777Z
Answers.Text: its probably worth noting that this is also important for your Drupal sites and others in the settings.php so that Drupal notes its https as well if your behind an ssl termination or a load balancer
Answers.UserDisplayName: Seamus Lee
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-01-02T22:48:58.293Z
Answers.Text: Yes, the problem I experienced is a bad configuration problem that needed to be fixed, though I think Civi could be more forgiving ...
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-12-21T21:46:05.560Z
Answers.LastActivityDate: 2017-12-22T19:28:26.790Z
Answers.LastEditDate: 2017-12-22T19:28:26.790Z
Answers.UserDisplayName: Alan Dixon
Body: <p>Drupal 7, CiviCRM 4.6, I've just switched a site from being a directory of one domain to it's own new domain. After clearing all caches and resetting the backend configuration, it's able to load the dashboard, but other pages result in what I believe is a race condition - specifically, loading the page seems to trigger the server into calling itself for the same page (i.e. generating an outgoing request to the url being requested). So it ends up in quite the death spiral of resource use.</p>
  
  <p>I know that 4.6 uses outgoing requests to itself to populate the dashboard, but that's not exactly the issue here. I also have noticed that 4.6 uses http requests to itself to identify it's own version, which is also a kind of crazy thing, and I wonder if that's what's creating the death spiral in this case.</p>
  
  <p>Any clues or similar experiences?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-12-21T19:38:49.333Z
Comments.Text: Is there any http / https redirection complicating things?
Comments.UserDisplayName: Aidan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-12-21T19:56:49.693Z
Comments.Text: I don't think so. After cutting off the spiral of death by restarting php-fpm, I'm left with about 40 entries in my varnishncsa log that show it was calling itself at the same url, no redirects. There's something in the code that is triggering a request to itself ... I have disabled all the extensions. I guess I could put something in the settings file to do a dump if it sees itself calling itself. ...
Comments.UserDisplayName: Alan Dixon
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-12-21T20:20:46.680Z
Comments.Text: OOh, when I try that, it still goes into a spiral of death!
Comments.UserDisplayName: Alan Dixon
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-12-21T21:22:39.780Z
Comments.Text: I also tried to intercept before the request goes out with some logic in Utils/System.php which is one place outgoing requests are built, but apparently that's not where this one is coming from. FWIW, there's no referrer and no user agent in the request either.
Comments.UserDisplayName: Alan Dixon
Tags: <drupal><installation>
Title: Race condition death spiral when changing a site's domain?
ThreadText: # Race condition death spiral when changing a site's domain?
  
  (Asked by: username_0 on 2017-12-21)
  
  Drupal 7, CiviCRM 4.6, I've just switched a site from being a directory of one domain to it's own new domain. After clearing all caches and resetting the backend configuration, it's able to load the dashboard, but other pages result in what I believe is a race condition - specifically, loading the page seems to trigger the server into calling itself for the same page (i.e. generating an outgoing request to the url being requested). So it ends up in quite the death spiral of resource use.
  
  I know that 4.6 uses outgoing requests to itself to populate the dashboard, but that's not exactly the issue here. I also have noticed that 4.6 uses http requests to itself to identify it's own version, which is also a kind of crazy thing, and I wonder if that's what's creating the death spiral in this case.
  
  Any clues or similar experiences?
  
  **Tags:** drupal, installation
  
  > **Comments:**
  > **username_1**: Is there any http / https redirection complicating things?  
  > **username_0**: I don't think so. After cutting off the spiral of death by restarting php-fpm, I'm left with about 40 entries in my varnishncsa log that show it was calling itself at the same url, no redirects. There's something in the code that is triggering a request to itself ... I have disabled all the extensions. I guess I could put something in the settings file to do a dump if it sees itself calling itself. ...  
  > **username_0**: OOh, when I try that, it still goes into a spiral of death!  
  > **username_0**: I also tried to intercept before the request goes out with some logic in Utils/System.php which is one place outgoing requests are built, but apparently that's not where this one is coming from. FWIW, there's no referrer and no user agent in the request either.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-12-21. Score: 2
  
  Not really a CiviCRM issue, but in case anyone else has a similar experience.
  As username_1 correctly guessed, it was indeed due to an http/https redirect - the one that comes from CiviCRM when you tell it to use https for admin/payment pages. Which is why it was okay on some pages, and why it was spawning new php processes for each one.
  The reason this site had the problem was due to my use of a separate ssl termination ("Pound") before it went to apache. When you do this, you have to tell apache how it can know if it's been through the termination (via the use of http headers). I hadn't done that for this site, so it kept redirecting itself to the same page, not aware that it was already https.
  I put in a redirect from the http to https site, and added the required apache vhost line:
  SetEnvIf X-Forwarded-Proto https HTTPS=on
  
  and the issue has now been resolved.
  
  > **Comments:**
  > **username_2**: its probably worth noting that this is also important for your Drupal sites and others in the settings.php so that Drupal notes its https as well if your behind an ssl termination or a load balancer  
  > **username_0**: Yes, the problem I experienced is a bad configuration problem that needed to be fixed, though I think Civi could be more forgiving ...  
  
  ---
  
  