This server does not handle hanging connections.

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...

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?

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?

I pass the key in the URL
http://drupalcode.org/project/httprl.git/blob/refs/heads/7.x-1.x:/httprl...

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.

Patch for you to test

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

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.

committed #13 patch to 6.x & 7.x. Thanks for testing!
http://drupalcode.org/project/httprl.git/commitdiff/f1dcf188b44e61cadabf...
http://drupalcode.org/project/httprl.git/commitdiff/062a595f7a1f2a5369b5...