Radovan Semancik wrote: > On 02/22/2016 04:07 PM, Michael Ströder wrote: >> Radovan Semancik wrote: >>> On 02/22/2016 02:13 PM, Michael Ströder wrote: >>>> There's no way around having decent error handling anyway. Permissive modify >>>> control won't help you there in general. And catching attributeOrValueExists >>>> and >>>> gracefully handle it is not a big deal. >>> [..] >>> But most importantly: I would rather like that error handling is trigged only if >>> there is an actual error. MidPoint does a very good error handling. But having >>> logfile full of errors that are in fact just a pretty normal operation is not a >>> nice thing. >> Whether LDAP result code attributeOrValueExists is treated as an error or just >> logged as "nothing to be seen here" is up to your code, isn't it? > > Depends on a layer. The operation will always be logged as LDAP error response. But it's up to your application whether a LDAP response code results in a warning/error log level message or a debug/info log level message. > The connector also does not know whether it is real error or not. This sounds strange to me. Connectors I implement for my customers always know whether something is a real error or not and then it decides whether to abort or ignore. >> BTW: If a single role change leads to write operations to more than entry you >> would need LDAP transaction support to really ensure atomicity of that single >> role change. > > Not really. I do not need atomicity. I just need eventual consistency. I can get > that without transactions. That's ok. >>>> As said: I've decided to handle groups in web2ldap in specific way and to >>>> provoke failure for concurrent writes based on stale data in general. >>> Yes, but if you "provoke" a failure you have to be sure that other components in >>> the system can handle that failure well. >> Yes. In case of web2ldap it even means handling the error in the UI. > > Well, that might be enough for web2ldap. But we are a "self-healing" system. Self-healing just means that if anything goes seriously wrong in a connector it will try to reach the target state by doing a full sync during next run. Nothing special in your product. >>> Or operations that replace the values. But the attributeOrValueExists error is >>> not going to help here. >> We have to distinguish various write operations in detail: >> attributeOrValueExists (for MOD_ADD) and its counterpart noSuchAttribute (for >> MOD_DELETE) solely helps if your modify request only contains *single* attribute >> values. > > Not even in that case. E.g. see above. You will not get the error if you are > re-adding a group that was deleted just a millisecond ago just because the > network latencies haven't turned up in your favor. Now this sounds suspicious to me. Are you using several MMR replicas to write to at the same time? If yes, here's some advice in good faith and without offense: DON'T DO THAT! > "Hey there! Maybe something wrong happened. Or maybe not. It may all be OK. > There is no way to be sure. So forget it. I just wanted to talk to you. Sorry to > bother you. And, by the way, your operation failed. Just for fun. Try something > else. I won't tell you what. Go figure. Bye." There's nothing wrong to log a debug/info message saying: "Ignored LDAP response code <foo> because of condition <bar>" Who is informed about what message depends on your log level routing. Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature