https://bugs.openldap.org/show_bug.cgi?id=6138
Howard Chu <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #7 from Howard Chu <[email protected]> --- (In reply to Hallvard Furuseth from comment #0) > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Might make this a tracking issue for Cancel/Abandon problems. > And/or copy some to separate ITSes, but they all seem interconnected: > > > Cancel(abandoned operation)-requests are not rejected. Thus slapd > sets o_cancel and turns an active Abandon into a Cancel. Presumably > that can confuse Cancel/Abandon handlers, like that in Syncprov. > > Similarly, Abandon(abandoned/cancelled operation) is not ignored. > connection_abandon() re-abandons abandoned/cancelled operations too. Both of the above checks are now uncommented / enabled. > However Syncprov:RefreshAndPersist abuses op->o_abandon: It sets it to > mean "Suppress the response. A copy of this operation will send it." > So if Cancel(op with o_abandon!=0) is fixed to respond protocolError > "already abandoned", presumably that breaks Cancel(RefreshAndPersist). > > I'm not touching it with a flagpole - I don't know syncprov. Help? syncprov has been changed to use the new SLAPD_ASYNCOP returncode so it no longer needs to muck with this. > Overlay retcode does something similar - sends a response and then sets > o_abandon. I can't see any reason why this is needed. It's been there since the initial commit but I'm removing it. Any return code != SLAP_CB_CONTINUE already prevents the frontend from sending its own response so there's no reason to set this here. > Cancel/Abandon can in any case fail by targeting the wrong operation > though: A connection can have multiple messages with the same IDs when > the response is sent and the client reuses the message ID, before the > old operation in slapd can clean up and finish. > > syncprov_op_abandon() identifies messages by (connid, msgid). Can > multiple messages with the same ID break that, or more importantly, > break what gets sent/written with syncrepl? Sounds like bad practice in clients, but should still be safe. The messages are queued in order, so only the first matching message will be abandoned. Presumably the first incoming abandon request can only refer to the first queued operation of that ID. > Anyway, the current code needs an o_abandon value which means "suppress > response". Or maybe "abandoned, except as far as future Abandon and > Cancel operations are concerned". Syncprov and Retcode need to handle > the various possible orderings of Cancel/Abandon vs Suppress, including > when they forward o_abandon from one operation to another. I haven't > looked too closely at that code either. Mooted by use of SLAPD_ASYNCOP returncode. -- You are receiving this mail because: You are on the CC list for the issue.
