3

Background

For some time now, and only in some occasions, when I run CRON (Status report), I see a huge error (About 170 rows) at the HTTPRL section (related to the HTTP Parallel Request & Threading Library module). It happens randomly - Sometimes it happens and sometimes it doesn't. When the error does not appear, the HHTPRL "section" in status report is all green. Here is a screenprint of it:

enter image description here

What I already tried

I've tried to play a bit with the HTTPRL preferences, but nothing really helped... For example, tried to change at "IP Address to send all self server requests to": from -1 to 1. Also tried to uncheck "Enable background callbacks", But IIRC nothings has changed.

The only changes I saw (When the error was apparent) were when I unchecked "Enable background callbacks", or otherwise, when I check-marked "Use httprl to handle drupal_http_request" --- When I ran Cron afterwards the error's text went from about 170 rows to 90 rows. But this data doesn't help me to understand Why the error was there on the first place and even worse - Why it appears randomly?

Bottom line

Is this a known problem? You might have an idea why this happens or a tip how to try to solve it?

6
  • 1
    This might be as simple as leaving that field blank, unless you're doing some interesting redirection of the base URL.
    – Screenack
    Aug 3, 2015 at 21:50
  • Hi, leaving this field blank didn't help... Moreover, It returns automatically to be "-1" right after I run Cron\Status report.
    – user16289
    Aug 3, 2015 at 23:38
  • 1
    Looking at the code suggests simple logic to determine your server's IP address but the logic isn't handling extracting the IP for your online site. Do you know the IP? If so, what happens if you enter it?
    – Screenack
    Aug 4, 2015 at 1:12
  • 1
    That sounds consistent with this bug ticket: drupal.org/node/2299009 Perhaps try using the dev version of the module. The stable version hasn't been updated since Jan 2014.
    – Screenack
    Aug 4, 2015 at 10:20
  • 2
    That "IP address..." setting definitely needs to be -1 because you need it to use the hostname to hit the server rather than the IP. My guess is that your server's just really slow and isn't responding fast enough to the test call in some cases. Either that or there's some reason why the server's hostname isn't being correctly deduced. Your error shows it's attempting to connect via IP which will never work. Would be interesting to see if there's an error with it trying to connect via hostname.
    – Aaron
    Aug 4, 2015 at 19:00

2 Answers 2

5
+50

The solution (or at least work around?) could be what is described in Comment # 8 of Issue # 2450725 related to the HTTP Parallel Request & Threading Library module:

change "'timeout' => 7," to "'timeout' => 1,"

This timeout is used in lock_acquire() that probably locks Drupal for 7 seconds, but in httprl config httprp waits only 5 seconds for a response.

Comment # 17 in that issue also contains a corresponding patch, which looks like so:

diff --git a/httprl.install b/httprl.install
index d7e2963..e2d4f04 100644
--- a/httprl.install
+++ b/httprl.install
@@ -177,7 +177,7 @@ function httprl_install_http_test($mode, $blocking = FALSE) {
       // Setup options array.
       'options' => array(
         'blocking' => $blocking,
-        'timeout' => 7,
+        'timeout' => 1,
         'max_redirects' => 0,
         'headers' => $headers,
       ),
0
0

I faced the same issue. Executing the following code did the trick:

variable_set('httprl_install_lock_time', 1);

I use devel/php. It can be done via drush as well:

drush php-eval "variable_set('httprl_install_lock_time', 1);"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.