[Date Prev][Date Next]
(ITS#3664) Back-meta and candidate selection - issues and fix
Full_Name: Pierangelo Masarati
OS: Linux (whitebox)
Submission from: (NULL) (188.8.131.52)
Submitted by: ando
back-meta suffers from a concurrency problem, because per-conn data may be
changed concurrently during operations. This may only happen when a client, on
a single connection, performs multiple asynchronous operations, so it is not
likely to impact common usage.
In the past there were (at least) two ITSes about back-meta that never got
ITS#3171, which I believe has little to do with the issue discussed here, and
ITS#2935, which addresses the persistence of candidate target selection across
operations. It is while addressing the latter that I found out the problem.
Candidate targets were selected on a per-operation basis, and a flag was set in
the per-conn structure. This may cause problems if multiple operations on the
same connection set different candidates.
The problem has been fixed by using a per-thread buffer that is used to store
the candidate target flags for each operation, while the per-connection
structure keeps the rest of the target data.
At the same time, I've completely reworked the candidate selection prcedure.
Now operations that strictly require one target to be selected, in case of
multiple candidates perform an internal search to determine which one is
appropriate, if any.
Other minor improvements have been added. The fix is in HEAD. I might see if
the essential portions can be backported to 2.2.