Hello--- your module is GREAT. Thank you.
I am running background process on a pantheon install-- which uses nginx and a couple of servers.
We have 2 servers in our load balancer, and occasionally these processes fail: this is the support note I received:
"You have to two applications on the Live environment. For modules that require a single application server or connection this can cause issues when the batch jobs as Drupal’s batch will dispatch these and they could either server.
The root of the problem is a majority of modules work on a single server infrastructure. Batches do run, we have some tasks on some of our own sites, but for some reason the way the host is defined in background_process. Hopefully setting one of these variables should get everything to work but there would be some trial and error. The issue queue may have already seen this but if not the maintainers may have some clues."
I am thinking of doing something like this in my settings.php Would this force it to one server?
<?php
$conf['background_process_service_hosts'] = array(
'mysite' => array(
'base_url' => 'http://127.0.0.1:13350',
'http_host' => 'mysite.com',
),
);
$conf['background_process_service_groups'] = array(
'default' => array(
'hosts' => array('mysite'),
)
);
?>
Comments
Comment #1
gielfeldt commentedIt will force it to one server, but not a specific one. It will be the one that the background process was originally issued from.
Say you have to servers with the ip's:
a) 1.2.3.4
b) 5.6.7.8
If a batch job is started from "a", it should stay on "a" throughout the process, as it will re-launch on 127.0.0.1.
To force it to a specific server, you will need to enter the exact ip (or unique hostname) of that server in the base_url option.
Comment #2
acb commentedSo you are saying that I should have two distinct configs in settings.php? one for each server, so that whichever server launches the process will maintain it?
(thanks again!)
Comment #3
gielfeldt commentedWell. Hmm. No. Sort of :-). It depends on what you want.
Your example should work (incidentally) as you want.
However, to explicitly configure it to work the way you describe you could do:
Comment #4
acb commentedThanks for the above…. Very helpful.
I received this from pantheon support also… which I am not sure is applicable:
>>>>>>
You can get the I.P. address dynamically when this is triggered, it should be part of the $_SERVER variable. From there you would have to set this somehow, possibly setting this when the job is kicked off.
I am not sure of the details about how the module works in much detail, but this may need to persist for the duration of the job, if the next batch is triggered it knows where to run. There may need to be some cleanup of that ID but the module may already do that, in which case setting the I.P. would be enough.
<<<<<<<<<
Does this sound at all plausible?
Comment #5
gielfeldt commentedThe solution they suggest will most likely work exactly like your own first example (the 127.0.0.1 example).
Comment #6
acb commentedHi, I think I am getting close…. could you take a look?
I added this:
However, now when running a background process, I am getting this in watchdog:
Notice: Undefined property: BackgroundProcess::$callback in BackgroundProcess->dispatch() (line 197 of /srv/bindings/9c6aa76ead80488b88df8d537e146d93/code/sites/all/modules/contrib/background_process/BackgroundProcess.class.php).
-----AND -----
Could not call service bfc2043c520b2b518ef9a173faa842fc for callback : stdClass Object ( [url] => 1.2.3.4:12428/bgp-start/bfc2043c520b2b518ef9a173faa842fc/3c282b5f3929ebb7217ed841bf296c76 [options] => Array ( [method] => POST [headers] => Array ( [User-Agent] => Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/6.1.2 Safari/537.74.9 [Accept] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 [Referer] => http://sprint31-lv-ns.gotpantheon.com/broadcast/5034 [Origin] => http://sprint31-lv-ns.gotpantheon.com [Content-Type] => application/x-www-form-urlencoded [Dnt] => 1 [Accept-Language] => en-us [X-Pantheon-Styx] => 1 [X-Forwarded-For] => 74.101.14.194, ::ffff:127.0.0.1,::ffff:127.0.0.1 [Surrogate-Capability] => styx="ESI/1.0" [Cookie] => has_js=1; SESS6049d2e68cce54c5e5c0e2a92b68aa58=UJfcqpAjtv-KCc9PpuWURWOntLR8qiQmIBV_5SwbUg4; has_js=1; Drupal.tableDrag.showWeight=0; hblid=yGt9hphwf0wQbUzN878pR6JODT1gFgkQ; olfsk=olfsk7364005933050066 [X-Varnish] => 200088023 [X-Pantheon-Client-Ip] => 74.101.14.194 [X-Forwarded-Port] => 59818 [X-Forwarded-Proto] => http [Host] => sprint31-lv-ns.gotpantheon.com [Connection] => close ) ) [code] => -1002 [uri] => Array ( [host] => 1.2.3.4 [port] => 12428 [path] => /bgp-start/bfc2043c520b2b518ef9a173faa842fc/3c282b5f3929ebb7217ed841bf296c76 ) [error] => missing schema [end] => 1397235199.6354 )
when starting a background process. … and nothing fires off.
(I have changed my ip in the above to 1.2.3.4).
Do you have any insight here?
Best, and THANKS for your patience,
ACB
Comment #7
gielfeldt commented"missing schema". You must include the schema (http or https) in the base_url.
However, I don't understand what you are trying to do with the above code. What's the DNS lookup used for?
Comment #8
acb commentedPantheon rotates cloud-server IPs on occasion, and changes ports as well… so they suggest we check once a day on cron.
I will try the http:// and report back.
UPDATE:
that seems to have done the trick; sorry for the silly question. However I have not tried it on the production (load-balanced) servers yet. I will let you know if we see any issues.
Thank you so much for your help.
Comment #9
acb commentedOK.... so I have to revive this thread.
I have been consistently getting this error:
As per our earlier discussion this runs on cron:
We have two web-heads on Pantheon. Sometimes this sets it correctly, but sometimes it gets the IP of one box, and the port of another.. Have I made a simple little mistake here, or is there something in the way they have set up their server environments that is off?
my_bg_host tends to have the right IP/Port in it. and the 'default' when I "determine default host" is 127.0.0.1 and on the same port.
Anyway, any enlightenment you could give would be great. This module (when it's working for me) is incredibly powerful. I just wish I could get it to be consistent.
Thank you.
Comment #10
acb commentedok... so now I am doing this, in order to get the correct IP/port Combination. The http_request of robots.txt feels clunky to me. Any thoughts?
Comment #11
gielfeldt commentedI've created a Pantheon account. I'll try to get my hands on this soon.
@acb You say the ports change as well?!? That may be a tough one to crack. Especially if we only have a DNS lookup to get this info, since DNS doesn't tell us anything about ports.
Comment #12
timani commented@giefeldt, you will need an account with at least two application servers in production. You can ping me when you are ready and I can get that setup for you.
I have not had much time to test this but the ports are returned in the $_SERVER variable and the full host and port included in the $_SERVER['HTTP_HOST'];
Here is a gist of the sanitized $_SERVER variable from a test script that dumps the var.
https://gist.github.com/timani/30482f6c1290c780ef57
My hunch is that this was missing a check to make sure the I.P. and the port are a match and return a 200 HTTP response code.
I could see this returning 2 I.P.s with the code from https://drupal.org/node/2233843#comment-8748697 but with the update to check for a 200, curious if this works. I tried to step through the logic to see how it would run but feedback would be needed as it appears to be correct.
Comment #13
gielfeldt commentedHi
I'm ready. I have a question, perhaps you know the answer :
Does such a setup as yours consists of a pool of known IP's and ports?
Comment #14
timani commentedHey @gielfeldt
Unfortunately not, with the number of servers we have know and we run containers that have access via random ports. The reason we do not have a fixed pool of I.P. addresses is because our provider can not guarantee the IPv4 addresses with be within a certain range anymore.
If you can send me a message I can make your site business level so you will have two application servers in the Live environment.
The limitation that I see for SSL is the I.P. addresses will serve the *.gotpantheon.com wilcard cert and generate an SSL connection exception.
Comment #15
gielfeldt commentedHi
I haven't really had the time to look at this, sorry :-(.
To recap (because it's been a while): Do I understand it correctly, that background batch jobs fail when using 127.0.0.1 as the default service host, IF the server switches IP during a batch run?
Comment #16
acb commentedWe are not using background batch, rather background process (e.g. background_process_start($function, $args).
What seems to be happening somehow is our background_process table seems to fill up with locked jobs. When it is doing so, it generally means that Pantheon has rotated our IP and Port to another server. Currently we are checking to see if it is a valid ip and port before on cron with the following code.
However, this doesn't help us when the port is changed between IP-rotations. However, things don't seem to work when we simply point to "http://mysite.com" in the $conf module.
Is there any way to make this work just using our domain name (e.g. http://mysite.com)?
Thanks SO MUCH for your help.
Comment #17
gielfeldt commentedHow about this:
Comment #18
gielfeldt commentedComment #19
Chris Charlton+1 on trying to figure this out. My prod environment has more than one web head so I'll give what I find in here a shot.