Hi, was wondering if you could shed some more light on the message "This server does not handle hanging connections" in my status report. It did dump a few arrays in the report. What am I looking for to troubleshoot this? Thanks in advance.

Files: 

Comments

What I do is test non blocking mode by setting a lock, and then having the URL (admin/httprl-test) that gets pinged release the lock. If the lock doesn't release then I assume your server didn't handle the non blocking request.
http://drupalcode.org/project/httprl.git/blob/626d36ba967541f30cd78b4433...

I know why it's not working. I use securepages, and the path admin/* is set to only be served via https. The test seems to send traffic to just the http://mysite, and does not handle the redirect to the https site.

If I add admin/httprl-test as a URL to ignore for securepages, it does work properly and comes back green. As an aside, perhaps this is also the issue with advagg and the yellow messages there telling me CSS and JS requests are not coming back when routed through the CDN.

advagg uses your files path, not the admin path; so that just means origin pull isn't working as I'm expecting it to. Does origin pull work for advagg files that are missing on your server?

OK, perhaps advagg is a different issue then. Yes, I am using it exclusively in origin pull mode (with async mode off, md5 checksums.) Not a big deal with that one, I need to upgrade it anyway since I am behind. I'll try again after an upgrade.

I'm puzzled by this message on the status report page.

You try to do a lock_release() in another request than the lock_acquire() was made. But the _lock_id() is different in each request, so It's unable to actually release the lock, even though it's called.

Am I missing something here?

The way I see it, these cross-request locks will never work with the current implementation in lock.inc?

Yes, the "lock id" (name) is transferred to the subrequests, but there are two components to the locking (name and value).

If you take a look at the lock_release() in lock.inc, then one of the conditions is value = _lock_id()

_lock_id() is generated per request via uniqid(mt_rand(), TRUE) which then would create a unique id per request.

Example:
- Request to /admin/reports/status
-- lock_acquire()
-- _lock_id() generates a unique number
-- lock is set using name: 'httprl_' . md5(mt_rand() . time()) and value: _lock_id()
-- A sub-request is made to /admin/httprl-test

- Request to /admin/httprl-test
-- lock_release(id) where id is transferred from the main request
-- _lock_id() generates a unique number
-- lock_release() now tries to release the lock based on name and value, but value (_lock_id()) differs from that in the main request.

On my system the non-blocking test fails on the status report page, and it seems to be only because of the sub-request not being able to release the lock due to the unique-id-per-request.

In my Background Process module I experienced the same problem and had to implement my own locking mechanism to work across requests.

Anyways, it's only used on the status report page as information, so it doesn't affect to functionality of HTTPRL as such. I still think it's a bug though, as it stalls my status report page. Perhaps I should file a new issue as a bug report?

EDIT: Then again I could wrong, because I guess you have it working somehow. I just can't understand how :-)

using memcache-lock.inc
http://drupalcode.org/project/memcache.git/blob/0441b1a008deeb89e6278666...

Looks like I need to call a custom version of lock_release if $conf['lock_inc'] is set to the default.

Ok, that explains it then. I'm just using the default database locking backend.

BTW, are there other locking backend's out there (APC, XCache, etc.)? And can we assume that it's only the core lock.inc that implements this unique lock_id per request?

I believe memcache is the only module that has its own $conf['lock_inc'] implementation.

Version:6.x-1.1» 6.x-1.x-dev
Component:Documentation» Code
Category:support» bug
Status:Active» Needs review
StatusFileSize
new921 bytes

Patch for you to test

StatusFileSize
new879 bytes

Forgot the bang in the if statement. This is the correct patch to test.

Status:Needs review» Reviewed & tested by the community

Works for me and it looks good. Though it might be future-incompatible with other locking backends, should they decide to implement a unique id per request mechanism like the core lock.inc. But that seems like a very low risk to me.

Status:Reviewed & tested by the community» Fixed

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.