Ding Fei [Fri, 4 Dec 2020 03:11:04 +0000 (11:11 +0800)]
ITS #9417 ldapexop exit with correct rc value
`rc` collects exit status all the way down but is not used at all? If `code`
comparison at exit is intended then there exists some path that leaves it in
garbage value, say when `ldap_whoami` or `ldap_cancel` fails.
Ondřej Kuzník [Thu, 16 Jan 2020 15:00:59 +0000 (15:00 +0000)]
Flush cache before calling dispose()
This needs to be confirmed:
Location based atomics do not imply a full fence of the same level. So
to get the code in dispose() read the actual data, it seems we need to
initiate a fence.
If we're idle, there might be objects pending cleanup for the last two
epochs. Unless another thread comes in and checks into a new epoch or we
shut down, they will linger forever.
If one of the objects was a connection, it wouldn't get closed and be
stuck in CLOSE_WAIT state, potentially refusing another ligitimate
connection if its socket address were to match the one we're yet to
close.
Ondřej Kuzník [Fri, 29 Mar 2019 12:56:24 +0000 (12:56 +0000)]
Implement read throttling when writes backlog
Reject operations in such a case with LDAP_BUSY. If read_event feature
is on, just stop reading from the connection. However this could still
result in deadlocks in reasonable situations. Need to figure out better
ways to make it safe and still protect ourselves.
Ondřej Kuzník [Fri, 17 Aug 2018 11:28:13 +0000 (12:28 +0100)]
Epoch based memory reclamation
Similar to the algorithm presented in
https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-579.pdf
Not completely lock-free at the moment. Also the problems with epoch
based memory reclamation are still present - a thread actively observing
an epoch getting stuck will prevent LloadConnections and LloadOperations
being freed, potentially running out of memory.
Ondřej Kuzník [Thu, 2 Aug 2018 09:00:24 +0000 (10:00 +0100)]
Switch to LDAP_OTHER when handling a lost upstream.
LDAP_UNAVAILABLE signals "the server is shutting down or a subsystem
necessary to complete the operation is offline", so intelligent clients
tend to infer the connection will not be usable any more, which is not
the case here.
Ondřej Kuzník [Fri, 23 Mar 2018 16:16:44 +0000 (16:16 +0000)]
Implement runtime monitor (un)registration
Unregistration is a hack and we shoould either make the subsystems into
an entry (if monitor allows subentry generation) or implement subsystem
unregistration in back-monitor.
Ondřej Kuzník [Wed, 21 Feb 2018 13:51:51 +0000 (13:51 +0000)]
Fix operation status tracking.
An operation is rejected iff it has to be dropped before we can find an
upstream for it (unless we handle it ourselves, that is). At that point
it is failed unless completed successfully.
This makes a difference for multi-stage binds which alternate between
'failed' (we are waiting on a server response) and 'completed' (server
did what we asked them to, waiting on client to continue).
Ondřej Kuzník [Wed, 14 Feb 2018 15:44:51 +0000 (15:44 +0000)]
Fix operation counts
Trying to abandon an operation does not automatically make it completed,
it might have failed already but we're just racing to reach the client
to record that.
Ondřej Kuzník [Thu, 8 Feb 2018 23:44:31 +0000 (23:44 +0000)]
Fix a race on bind response processing.
During response processing, an upstream connection could be marked ready
after a different bind had already been allocated to it, thus allowing
two binds to be in progress on the same connection.