diff options
author | David Kalnischkies <david@kalnischkies.de> | 2016-04-06 01:08:57 +0200 |
---|---|---|
committer | David Kalnischkies <david@kalnischkies.de> | 2016-04-07 13:48:31 +0200 |
commit | 38f8704e419ed93f433129e20df5611df6652620 (patch) | |
tree | b49599c1b86bb22109fc1f68468e385baf6d9ce0 /test/integration/Packages-releasefile-verification-new | |
parent | 57f16d51f4158dce1a49f6d5f5f05f057125b871 (diff) |
stop handling items in doomed transactions
With the previous commit we track the state of transactions, so we can
now use our knowledge to avoid processing data for a transaction which
was already closed (via an abort in this case).
This is needed as multiple independent processes are interacting in the
process, so there isn't a simple immediate full-engine stop and it would
also be bad to teach each and every item how to check if its manager
has failed subordinate and what to do in that case.
In the pdiff case, which deals (potentially) with many items during its
lifetime e.g. a hashsum mismatch in another file can abort the
transaction the file we try to patch via pdiff belongs to. This causes
some of the items (which are already done) to be aborted with it, but
items still in the process of acquisition continue in the processing and
will later try to use all the items together failing in strange ways as
cleanup already happened.
The chosen solution is to dry up the communication channels instead by
ignoring new requests for data acquisition, canceling requests which are
not assigned to a queue and not calling Done/Failed on items anymore.
This means that e.g. already started or pending (e.g. pipelined)
downloads aren't stopped and continue as normal for now, but they remain
in partial/ and aren't processed further so the next update command will
pick them up and put them to good use while the current process fails
updating (for this transaction group) in an orderly fashion.
Closes: 817240
Thanks: Barr Detwix & Vincent Lefevre for log files
Diffstat (limited to 'test/integration/Packages-releasefile-verification-new')
0 files changed, 0 insertions, 0 deletions