This code seems to cause an endless loop on my localhost. Not have much time to investigate more into the issue but seems like it's caused by something related to this error message:

Warning: (null)(): xxx is not a valid cURL handle resource

do {
    // This loop is only necessary for libcurl earlier than 7.20.0, however
    // RHEL 5 has just that. Otherwise a simple call would do.
    do {
      $multi_result = curl_multi_exec($curl_purges, $active);
    } while ($multi_result == CURLM_CALL_MULTI_PERFORM);
    // Block until there is activity on any of the handlers. Avoids
    // busywaiting.
    if ($multi_result == CURLM_OK) {
      $select_result = curl_multi_select($curl_purges);
    }
    if ($multi_result != CURLM_OK || $select_result == -1) {
    // @TODO: error handling. Something truly awkward happened.
    return FALSE;
    }
  } while ($select_result != -1 && $active && $multi_result == CURLM_OK);

CommentFileSizeAuthor
#3 2124757-3.patch1.34 KBmike.davis

Comments

ngocketit’s picture

Title: Forever loop inpurge_issue_requests_curl() on localhost » Forever loop in purge_issue_requests_curl() on localhost
mike.davis’s picture

I'm getting similar issue. On a bit of investigation it seems that the $select_result flag is always set to 0 so just gets caught in an endless loop. Still doing some further investigation.

mike.davis’s picture

Issue summary: View changes
StatusFileSize
new1.34 KB

This outer loop has the comment about "only necessary for libcurl ealier than 7.20.0". Our servers are using libcurl 7.19.7 so this outer loop shouldn't be required. Removing this outer loop seemed to sort out the hanging of the process for me.

do {
    // This loop is only necessary for libcurl earlier than 7.20.0, however
    // RHEL 5 has just that. Otherwise a simple call would do.

  ......    

  } while ($select_result != -1 && $active && $multi_result == CURLM_OK);
mike.davis’s picture

Maybe a check for the version of libcurl could be done to handle this better?

ngocketit’s picture

This seems to be also causing the issue if the configuration of Varnish port is wrong. For example, if Varnish is running on port 80 but it's set to another port in admin/config/development/performance/purge then the loop may run forever, which makes it EXTREMELY difficult to debug. It took us several days to pinpoint the module & the function that caused the timeout error.

japerry’s picture

Status: Active » Closed (outdated)

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.