Re: Local + LDAP new entries generating Duplicate Key errors on local

Tue, 03 Apr 2018 03:15:16 -0700 

Hi Adam,

On 02/04/2018 20:22, Adam Levine wrote:

Francesco:

    thank you for your response and guidance.

    My mapping is identical to the demo site.
    So, thanks to your email, I've found a few things and made some changes.
    1:  The pull task was firing repeatedly because I'd placed a timer on it without realizing. 

Clear.


    2:  There was no pull policy defined.
             I created one:
                  Conflict Resolution:  Ignore
                  Group:    rule type of plain attributes, and I selected "name". 

    I ran a pull cycle, and the error was no longer there.
   But, I'm not sure if the error has been resolved because of the resolution strategy I chose, or because it's able to match on the name.  I looked at the default correlation, and it appears it's doing the same attribute matching, which makes me think my problem was resolved by choosing "ignore".  I changed the strategy to first match, and again, no errors on pull.
Conflict resolution comes into place when more than an internal match is found: I don't think this was your case. 

Adding a matching rule based on Group name was the good move.
If I'm understanding this correctly, without an explicit pull policy in place, the default is to create, rather than update.  And using first or last match, uses the first/last in LDAP as the source of changes to update internal DB.  But, I'm not sure how "all" is then used.
When no pull policy is in place, Syncope attempts anyway to perform some matching based on the row in the mapping which is flagged as "Remote Key": it seems that, in your configuration, this kind of match is not working, and the pull policy matching rule solved the issue. 

Regards.
On Mon, Apr 2, 2018 at 11:50 AM, Francesco Chicchiriccò <[email protected] <mailto:[email protected]>> wrote: 

    Hi Adam,
    shortly: there is a problem in your LDAP mapping.

    The errors reported below are consequence of a Pull Task's
    execution, where Syncope attempts to *create* Groups (according to
    the provided Mapping for the External Resource for which the Pull
    Task is executed), while it should instead *update* Groups.

    Why does it fail, then? It fails because the matching process [1]
    is not able to correctly identify the Group in Syncope which
    should match the given Group on LDAP.

    Could you please report your LDAP Group mapping?

    Regards.

    [1]
    https://syncope.apache.org/docs/reference-guide.html#provisioning-pull
    <https://syncope.apache.org/docs/reference-guide.html#provisioning-pull>



    On 02/04/2018 11:30, Adam Levine wrote:

    I'm coming up to speed with Syncope, so this could be a newbie
    mistake, and I'm not sure how to fully trace/debug what's
    happening.  Please let me know what extra relevant information I
    can provide.


    v208
    Maven
    MariaDB 10.2.11
    ApacheDS 2.0.0-M24

    I have the LDAP connector wired up, and a singular instance for
    managing users and groups; this is the only external resource I have.

    I can create groups and users with no problem.

    If I connect them to the LDAP resource, they populate in DS.  I
    can edit values, and they are propagated to DS.

    However, the core.log fills up with repeated errors about a
    duplicate entry.   If I don't connect the user/group to LDAP,
    there are no errors in the log.  If I disconnect the user/group
    from LDAP, the log entries stop.

    This happens even on the first entry, so there's no chance
    there's actually a pre-existing entry.

    Thank you in advance for your assistance.


    Log Snippets:

    03:20:02.358 ERROR
    org.apache.syncope.core.provisioning.api.pushpull.SyncopeResultHandler
    - Could not create GROUP 72221ad0-d819-42f3-a0bb-1d21162866b1
    org.apache.openjpa.persistence.PersistenceException: The
    transaction has been rolled back.  See the nested exceptions for
    details on the errors that occurred.
    at
    org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2368)
    ~[openjpa-kernel-2.4.2.jar:2.4.2]
    at
    org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2205)
    ~[openjpa-kernel-2.4.2.jar:2.4.2]
    .....

    Caused by: org.apache.openjpa.persistence.EntityExistsException:
    (conn=1464) Duplicate entry 'abvc' for key 'U_SYNCGRP_NAME'
    {prepstmnt 1442070129 INSERT INTO SyncopeGroup (id, creationDate,
    creator, lastChangeDate, lastModifier, status, workflowId, name,
    REALM_ID, GROUPOWNER_ID, USEROWNER_ID) VALUES (?, ?, ?, ?, ?, ?,
    ?, ?, ?, ?,          ?)} [code=1062, state=23000]
    at
    org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4988)
    ~[openjpa-jdbc-2.4.2.jar:2.4.2]
    at
    
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4963)
    ~[openjpa-jdbc-2.4.2.jar:2.4.2]
    at
    org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:133)
    ~[openjpa-jdbc-2.4.2.jar:2.4.2]
    at
    org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:75)
    ~[openjpa-jdbc-2.4.2.jar:2.4.2]

    ....

    Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException:
    (conn=1464) Duplicate entry 'abvc' for key 'U_SYNCGRP_NAME'
    {prepstmnt 1442070129 INSERT INTO SyncopeGroup (id, creationDate,
    creator, lastChangeDate, lastModifier, status, workflowId, name,
    REALM_ID, GROUPOWNER_ID, USEROWNER_ID) VALUES (?, ?, ?, ?, ?, ?,
    ?, ?, ?, ?, ?)             } [code=1062, state=23000]
    at
    
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:218)
    ~[openjpa-lib-2.4.2.jar:2.4.2]
    at
    
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:194)
    ~[openjpa-lib-2.4.2.jar:2.4.2]
    at
    
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$1000(LoggingConnectionDecorator.java:58)
    ~[openjpa-lib-2.4.2.jar:2.4.2]
    at
    
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:1133)
    ~[openjpa-lib-2.4.2.jar:2.4.2]
    at
    
org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:275)
    ~[openjpa-lib-2.4.2.jar:2.4.2]



--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

Reply via email to