Re: LDAP Write then Read On-screen Object-not-found Error When Adding Address

Zitat von Andy Dorman <[email protected]>:

> Quoting Jan Schneider <[email protected]>:
>
>> Zitat von Andy Dorman <[email protected]>:
>>
>>> Our Horde setup uses OpenLDAP for authentication and personal  
>>> address books.
>>>
>>> Our OpenLDAP setup is a master LDAP server replicating to local  
>>> LDAP running on each webmail machine.  All the local LDAP  
>>> processes are configured to redirect writes to the master which  
>>> are then replicated back, usually in less than a second.
>>>
>>> I have run into a problem when adding an address book entry.   
>>> After submitting a new entry we get a Horde "object not found"  
>>> error up on the screen.  If we navigate back to the address book  
>>> we can see the new entry has been added.
>>>
>>> I assumed this probably meant Turba was checking for the new  
>>> address before it has been replicated back to the local LDAP.
>>>
>>> However, I found a clever bit of work in  
>>> /usr/share/horde/turba/lib/Form/AddContact.php that is obviously  
>>> intended to avoid problems with replication delay most of the  
>>> time...except it doesn't actually appear to work as intended.
>>>
>>> The code block looks like this:
>>>
>>> // Try 3 times to get the new entry. We retry to allow setups like
>>> // LDAP replication to work.
>>> for ($i = 0; $i < 3; ++$i) {
>>>   try {
>>>       $ob = $driver->getObject($key);
>>>       $notification->push(sprintf(_("%s added."),  
>>> $ob->getValue('name')), 'horde.success');
>>>       $url = empty($info['url'])
>>>           ? $ob->url('Contact', true)
>>>           : new Horde_Url($info['url']);
>>>       $url->redirect();
>>>   } catch (Horde_Exception_NotFound $e) {
>>>   }
>>>   sleep(1);
>>> }
>>>
>>> I am not an experienced PHP programmer (my background is mostly  
>>> perl), but it looked to me like the first time through the loop  
>>> the getObject call was failing (as expected while replication was  
>>> catching up) and the catch call to Horde_Exception_NotFound was  
>>> triggering the on-screen error report.
>>>
>>> As an experiment I replaced "Horde_Exception_NotFound" with  
>>> "Exception" and the on-screen error report is gone and the new  
>>> addresses are successfully added.
>>>
>>> So is there possibly a way to call Horde_Exception_NotFound in the  
>>> catch argument above and NOT have it post the on-screen error?
>>>
>>> If someone can confirm this is actually a bug and not something I  
>>> have mis-configured, I will post a bug report.
>>
>> No, this just means that the exception thrown from getObject() is  
>> *not* a Horde_Exception_NotFound. The question is, why not, and  
>> what else is it? Add a Horde::debug($e); call below your catch line  
>> (using Exception instead of Horde_Exception_NotFound) and let us  
>> know the outcome in /tmp/horde_debug.txt.
>>
>> -- 
>> Jan Schneider
>> The Horde Project
>> http://www.horde.org/
>> https://www.facebook.com/hordeproject
>>
>> -- 
>> turba mailing list
>> Frequently Asked Questions: http://wiki.horde.org/FAQ
>> To unsubscribe, mail: [email protected]
>
> Jan, thanks...The debug output is a bit verbose, but below are the  
> first and last snippets.  The complete file is attached.  The add  
> was successful.
>
> 2015-02-12T21:36:38+00:00 DEBUG: Variable information:
> object(Turba_Exception)#292 (10) {
>   ["details"]=>
>   NULL
>   ["logged"]=>
>   bool(false)
>   ["_logLevel":protected]=>
>   int(0)
>   ["message":protected]=>
>   string(32) "Read failed: (32) No such object"
>   ["string":"Exception":private]=>
>   string(0) ""
>   ["code":protected]=>
>   int(0)
>   ["file":protected]=>
>   string(42) "/usr/share/horde/turba/lib/Driver/Ldap.php"
>   ["line":protected]=>
>   int(264)
>   ["trace":"Exception":private]=>
>   array(4) {
>     [0]=>
>     array(6) {
>       ["file"]=>
>       string(37) "/usr/share/horde/turba/lib/Driver.php"
>       ["line"]=>
>       int(833)
>       ["function"]=>
>       string(5) "_read"
>       ["class"]=>
>       string(17) "Turba_Driver_Ldap"
>
> ... details of the test address being added
>
>     [1]=>
>     array(6) {
>       ["file"]=>
>       string(37) "/usr/share/horde/turba/lib/Driver.php"
>       ["line"]=>
>       int(869)
>       ["function"]=>
>       string(10) "getObjects"
>       ["class"]=>
>       string(12) "Turba_Driver"
>       ["type"]=>
>       string(2) "->"
>       ["args"]=>
>       array(1) {
>         [0]=>
>         array(1) {
>           [0]=>
>           string(117)  
> "[email protected],[email protected],ou=addresses,o=antespam.com"
>         }
>       }
>     }
>     [2]=>
>     array(6) {
>       ["file"]=>
>       string(46) "/usr/share/horde/turba/lib/Form/AddContact.php"
>       ["line"]=>
>       int(87)
>       ["function"]=>
>       string(9) "getObject"
>       ["class"]=>
>       string(12) "Turba_Driver"
>       ["type"]=>
>       string(2) "->"
>       ["args"]=>
>       array(1) {
>         [0]=>
>         string(117)  
> "[email protected],[email protected],ou=addresses,o=antespam.com"
>       }
>     }
>     [3]=>
>     array(6) {
>       ["file"]=>
>       string(30) "/usr/share/horde/turba/add.php"
>       ["line"]=>
>       int(68)
>       ["function"]=>
>       string(7) "execute"
>       ["class"]=>
>       string(21) "Turba_Form_AddContact"
>       ["type"]=>
>       string(2) "->"
>       ["args"]=>
>       array(0) {
>       }
>     }
>   }
>   ["previous":"Exception":private]=>
>   NULL
> }
>
> Backtrace:
> 1. Turba_Form_AddContact->execute() /usr/share/horde/turba/add.php:68
> 2. Horde::debug() /usr/share/horde/turba/lib/Form/AddContact.php:94
>
> -- 
> Andy--------------------------------
> This message was sent using FanMailPlus Webmail.

Fixed in Git.

-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject

-- 
turba mailing list
Frequently Asked Questions: http://wiki.horde.org/FAQ
To unsubscribe, mail: [email protected]