Hi Clément,
for solving my problem I have downloaded your source code and tried to find out
where the problem was.
Indeed I am now able to synchronize a group with lots of members (> 32 k)
without errors. What I had to do is to put a timeout on the LDAP environment in
the source code:
In org.lsc.jndi.JndiServices.java, line 172:
connProps.put("com.sun.jndi.ldap.read.timeout", "300000");
Maybe it would be helpful for future users to be able to configure that via
configuration file.
Well, this problem is solved, now to the next one :)
If a group in the source LDAP gets empty the group in the destination stays
unchanged, i.e. it will not be emptied as well - Unless the amount of members
in the destination gets lower than at about 5000. Then it is synchronized.
Funny: If ihe source group is not completely empty but contains still 1 person,
everything works well and the groups are synchronized, even if there are much
more than 5000 people in the destination group.
I have checked again the participated source code. During the synchronization
process the method org.lsc.beans.LscBeans.getDatasetById(final String id) is
invoked. This method returns datasets.get(id.toLowerCase()).
I have checked all parameters - everything is good and contains the right
values. Also the value "datasets" is ok and contains members as expected. BUT:
datasets.get(id.toLowerCase()) is null! (Which leads to the situation that
the BeanComparator sees an empty source, an empty destination, an operationType
"UNKNOWN" and so does not do anything). Unless, as I said, the amount of
destination members gets < approx. 5000 persons. Without having changed
anything but the amount of members in the destination there is now a datatsets
value != null and the group is synchronized and thus emptied finally.
No errors are displayed, neither in debug mode. Just:
Aug 04 12:31:45 - DEBUG - In object "CN=SYNC-TEST,xxxxx": Attribute "member"
will not be written to the destination
....
Aug 04 12:31:45 - INFO - All entries: 1, to modify entries: 0, successfully
modified entries: 0, errors: 0
It is again a couple of days I deal with this problem. Any idea anybody?
Thank you in advance,
Jutta
--------------------
Jutta Biernath
Freie Universität Berlin
Zentraleinrichtung für Datenverarbeitung (ZEDAT)
Identity & Customer Management, FUDIS
Fabeckstr. 32
14195 Berlin
Tel. +49 30 838-75090
Fax +49 30 838-475090
Von: Biernath, Jutta [mailto:[email protected]]
Gesendet: Donnerstag, 16. Juli 2015 14:24
An: Clément OUDOT <[email protected]>; TAMONE Francois
<[email protected]>; [email protected]
Cc: 'FUDIS' <[email protected]>
Betreff: AW: [lsc-users] javax.naming.NamingException: LDAP response read timed
out
Hi Clément, hi François,
>>>> would advice to set threads to 1 (-t1). You indeed found the good
>>>> parameter to set the timeout value: -i. But it is not normal to have an
>>>> error, what shows the log file?
it seems that the error has something to do with the threading. Reproducing the
error on a high debug level shows:
Jul 16 13:26:15 - ERROR - Error while modifying entry XXX in directory
:javax.naming.NamingException: LDAP response read timed out, timeout
used:-1ms.; remaining name 'XXX'
Jul 16 13:26:15 - ERROR - Error while synchronizing ID XXX:
java.lang.Exception: Technical problem while applying modifications to the
destination
Jul 16 13:26:15 - DEBUG - java.lang.Exception: Technical problem while applying
modifications to the destination
java.lang.Exception: Technical problem while applying modifications to the
destination
at org.lsc.SynchronizeTask.run(AbstractSynchronize.java:825)
[lsc-core-2.1.3.jar:na]
at org.lsc.SynchronizeTask.run(AbstractSynchronize.java:709)
[lsc-core-2.1.3.jar:na]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_75]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_75]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_75]
Again, the group was nevertheless synchronized.
>>>>> Unfortunately not, because LSC must get the full entry to compare it to
>>>>> the destination entry and compute the differences.
I understand that you must touch the entire group to identify which differences
are to be done. But after identifiying them it would be possible to add/remove
just the (formerly) identified memberships of a group, I think.
Best regards,
Jutta
--------------------
Jutta Biernath
Freie Universität Berlin
Zentraleinrichtung für Datenverarbeitung (ZEDAT)
Identity & Customer Management, FUDIS
Fabeckstr. 32
14195 Berlin
Tel. +49 30 838-75090
Fax +49 30 838-475090
_______________________________________________________________
Ldap Synchronization Connector (LSC) - http://lsc-project.org
lsc-users mailing list
[email protected]
http://lists.lsc-project.org/listinfo/lsc-users
