| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\ |
|
| |\ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
after spending hours trawling through the qi code and its history,
Matthew and I are convinced that qi:add_to_journal/3 is unnecessarily
general, handling a case that can never arise, namely adding an 'ack'
when we do have an entry for the given sequence number but that entry
does no contain a 'del'.
add_to_journal/3 gets called, indirectly, from four places:
1) load_journal/1. This is always called with no segements in the
State. So all the segment journal entries originate from the very
add_journal/3 code. And the only way we'd end up with an entry of the
form {Pub, no_del, no_ack} and get an 'ack' is if the journal
contained a pub and (later) an ack, with no del inbetween. That can
only happen through a misuse of the qi API. Which doesn't happen. And
there are plenty of other cases (e.g. duplicate dels or acks) where qi
insists on callers doing the right thing.
2) publish/5
This ends up adding a {?PUB, no_del, no_ack} entry, so is of no
direct concern to our investigation.
3) deliver_or_ack/3
This would hit the aforementioned {Pub, no_del, no_ack} & 'ack' case
only if we lost a 'del'.
4) recover_message/5
this only adds an 'ack' to the segment journal if either a) the
combination of the segment entries and the segment journal produces an
entry {?PUB, del, no_ack}, or b) it's just added a 'del' (thus making
a {Pub, no_del, no_ack} entry impossible). Re (a)... for there to be a
combined entry of {?PUB, del, no_ack} when the segment journal
contains {Pub, no_del, no_ack} (which would trigger the case we are
concerned about), the segment would have to contain a 'del' w/o a
'pub', which is impossible.
|
| | |\ |
|
| | | | |
|
| | |\ \ |
|
| | | | | |
|
| | |\ \ \ |
|
| | |/ / / |
|
| | |\ \ \ |
|
| | |\ \ \ \ |
|
| | | |\ \ \ \ |
|
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
plus some tests to go with that
And a tweak to the "become 1.0" API
|
| | | | |\ \ \ \
| | | |/ / / / / |
|
| | |\ \ \ \ \ \
| | | |/ / / / /
| | |/| | | | | |
|
| | | | | | | | |
|
| | |\ \ \ \ \ \ |
|
| | | |\ \ \ \ \ \ |
|
| | | | |\ \ \ \ \ \ |
|
| | | | | |\ \ \ \ \ \ |
|
| | | | | |\ \ \ \ \ \ \ |
|
| | | | | | |\ \ \ \ \ \ \ |
|
| | | | | | | |\ \ \ \ \ \ \ |
|
| | | | | | | | |\ \ \ \ \ \ \ |
|
| | | | | | | | | |\ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | | | |
|
| | | | |\ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | |_|_|_|_|_|/ / / / / / /
| | | | |/| | | | | | | | | | | | |
|
| | | | | |\ \ \ \ \ \ \ \ \ \ \ \
| | | | | | |_|/ / / / / / / / / /
| | | | | |/| | | | / / / / / / /
| | | | | | | |_|_|/ / / / / / /
| | | | | | |/| | | | | | | | | |
|
| | | | | |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | |_|_|/ / / / / / /
| | | | | | |/| | | | | | | | | |
|
| | | | | | |\ \ \ \ \ \ \ \ \ \
| | | | | | | |/ / / / / / / / /
| | | | | | |/| | | | | | | | | |
|
| | | | | | | |\ \ \ \ \ \ \ \ \ |
|
| | | | | |\ \ \ \ \ \ \ \ \ \ \ \
| | | | | | |/ / / / / / / / / / /
| | | | | |/| | | | | | | | | | | |
|
| | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
so it can distinguish between 'ready' messages and those pending ack
|
| | | | | | |\ \ \ \ \ \ \ \ \ \ \
| | | | | | | |_|/ / / / / / / / /
| | | | | | |/| | | | | | | | | |
| | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
which involved tweaking the variable_queue_with_holes result slightly,
and ripping out a whole bunch of now-redundant test code.
|
| | | | | | | |\ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | |\ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | | | | | | | | |
|
| | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
we implement this as a zipper over three iterators
|
| | | | | | | | |\ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | |\ \ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | |\ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ |
|
| | | | | | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |
which is rather conflict-ridden; essentially requiring the rewriting
of the crux of the change in bug25400 in the context of new iterator.
|
| | | | | | | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | | |_|_|_|_|_|/ / / / / / / / / /
| | | | | | | | |/| | | | | | | | | | | | | | | |
|
| | | | | | | |\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
| | | | | | | | |_|/ / / / / / / / / / / / / / /
| | | | | | | |/| | | | | | / / / / / / / / / /
| | | | | | | | | |_|_|_|_|/ / / / / / / / / /
| | | | | | | | |/| | | | | | | | | | | | | | |
|