You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@syncope.apache.org by Adam Levine <ad...@gmail.com> on 2018/04/02 09:30:26 UTC
Local + LDAP new entries generating Duplicate Key errors on local
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]
Re: Local + LDAP new entries generating Duplicate Key errors on local
Posted by Francesco Chicchiricc�� <il...@apache.org>.
On 2018/04/03 10:14:57, Francesco Chicchiriccò <il...@apache.org> wrote:
> 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.
Update: I have found that the LDAP connector configuration in the demo site (which is also the same configuration used by integration tests and delivered with the standalone distribution), reports, under "Uid Attribute for groups" the value "entryUUID": if you replace this with "cn", then the Pull Policy rule mentioned below is not necessary.
Hope this clarifies.
Regards.
> > On Mon, Apr 2, 2018 at 11:50 AM, Francesco Chicchiriccò
> > <ilgrosso@apache.org <ma...@apache.org>> 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/
>
>
Re: Local + LDAP new entries generating Duplicate Key errors on local
Posted by Francesco Chicchiriccò <il...@apache.org>.
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ò
> <ilgrosso@apache.org <ma...@apache.org>> 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/
Re: Local + LDAP new entries generating Duplicate Key errors on local
Posted by Adam Levine <ad...@gmail.com>.
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.
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.
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.
Have I got this all sorted?
thank you !
On Mon, Apr 2, 2018 at 11:50 AM, Francesco Chicchiriccò <ilgrosso@apache.org
> 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
>
>
> 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 Excellencehttp://www.tirasa.net/
>
> Member at The Apache Software Foundation
> Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMailhttp://home.apache.org/~ilgrosso/
>
>
Re: Local + LDAP new entries generating Duplicate Key errors on local
Posted by Francesco Chicchiriccò <il...@apache.org>.
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
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/