[horde] Sharing user information between hooks

[Jens Wahnes]

On Mon, Nov 02 2015, at 14:40:17 +0000, Michael J Rubinsky wrote:

> Quoting Jens Wahnes <wahnes at uni-koeln.de>:
>> On Thu, Oct 29 2015, at 16:53:10 +0000, Michael J Rubinsky wrote:
>>> Actually, the only place that this might be wrong is in the lock/unlock
>>> methods. Setting/deleting should work as expected.
>>> Horde_HashTable_Base:: has set/delete/get etc... methods that call a
>>> hkey() method which adds the prefix. After the prefix is added, the
>>> concrete _set/_delete etc... methods are called using the already
>>> prefixed keys. You'll have to check there to see why it's not working.

>>> Alternatively, check that the expected config values are being grabbed
>>> in Horde_Core_Factory_Hashtable.

>> To me, that seems to be the case.  In the debug info I get (I added a
>> statement "Horde::debug($memcache)"), the prefix info is present.
>> Here's an excerpt from that:
>>
>>
>> object(Horde_HashTable_Memcache)#125 (4) {
>>   ["_memcache":protected]=>
>>   object(Horde_Memcache)#121 (6) {
>>     ["_locks":protected]=>
>>     array(0) {
>>     }
>>     ["_logger":protected]=>
>>     object(Horde_Core_Log_Wrapper)#95 (0) {
>>     }
>>     ["_memcache":protected]=>
>>     object(Memcache)#124 (2) {
>>       ["connection"]=>
>>       resource(11) of type (memcache connection)
>>       ["_failureCallback"]=>
>>       array(2) {
>>         [0]=>
>>         *RECURSION*
>>         [1]=>
>>         string(8) "failover"
>>       }
>>     }
>>     ["_noexist":protected]=>
>>     array(0) {
>>     }
>>     ["_params":protected]=>
>>     array(10) {
>>       ["compression"]=>
>>       bool(true)
>>       ["hostspec"]=>
>>       array(2) {
>>         [0]=>
>>         string(9) "localhost"
>>         [1]=>
>>         string(26) "foo.bar.example.com"
>>       }
>>       ["large_items"]=>
>>       bool(true)
>>       ["persistent"]=>
>>       bool(true)
>>       ["port"]=>
>>       array(2) {
>>         [0]=>
>>         string(5) "11211"
>>         [1]=>
>>         string(5) "11211"
>>       }
>>       ["prefix"]=>
>>       string(8) "HordeSam"
>>       ["weight"]=>
>>       array(2) {
>>         [0]=>
>>         string(2) "90"
>>         [1]=>
>>         string(2) "10"
>>       }
>>       ["c_threshold"]=>
>>       int(1200)
>>       ["umask"]=>
>>       int(63)
>>       ["logger"]=>
>>       object(Horde_Core_Log_Wrapper)#95 (0) {
>>       }
>>     }
>>
>>
>> When I grepped through the log file, I could see that there is only one
>> other type of memcache keys which do not seem to include the set
>> prefix.  They are related to IMAP access and look like this:

> So, it's only the imap client cache that exhibits this behavior?

Well, it's both Horde_Imap_Client and the memcache code in my very own
hook that show this behavior.  I only brought up Horde_Imap_Client
because it's an example of code *not* written by me that shows this
behavior.  So I was hoping it might lead to a clue what is wrong with my
code when the same thing is happening at (only) one other place.


Jens
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.horde.org/archives/horde/attachments/20151103/097c0b88/attachment.bin>