2 added 1 character in body
source | link

Appending to a persistent log on A should suffice. This copes with reboots and network partitions to achieve eventual consistency, or to signal breakage which prevents such convergence. With amortized group commit it can take less than a single write to persist a log entry.

You suggested making B responsible for unmarking state. I disagree. Only A becomes aware of new work, and only A should be responsible for tracking it and reporting errors such as timeouts. B sends idempotent message(s) to A, anand A updates the state, re-querying at intervals as needed.

At step 0, A becomes aware of a new request and logs it. That constitutes an obligation A must later discharge by some deadline - A will continuously perform, and repeat, the subsequent steps until A learns that request processing has completed.

Some requests will be longer than others. Estimates of processing time will become available on A and on B, perhaps revised as processing continues. Such estimates may be fed back to A so it will seldom produce false-positive timeouts. Think of it as a keep alive message that says "still working, still working".

Appending to a persistent log on A should suffice. This copes with reboots and network partitions to achieve eventual consistency, or to signal breakage which prevents such convergence. With amortized group commit it can take less than a single write to persist a log entry.

You suggested making B responsible for unmarking state. I disagree. Only A becomes aware of new work, and only A should be responsible for tracking it and reporting errors such as timeouts. B sends idempotent message(s) to A, an A updates the state, re-querying at intervals as needed.

At step 0, A becomes aware of a new request and logs it. That constitutes an obligation A must later discharge by some deadline - A will continuously perform, and repeat, the subsequent steps until A learns that request processing has completed.

Some requests will be longer than others. Estimates of processing time will become available on A and on B, perhaps revised as processing continues. Such estimates may be fed back to A so it will seldom produce false-positive timeouts. Think of it as a keep alive message that says "still working, still working".

Appending to a persistent log on A should suffice. This copes with reboots and network partitions to achieve eventual consistency, or to signal breakage which prevents such convergence. With amortized group commit it can take less than a single write to persist a log entry.

You suggested making B responsible for unmarking state. I disagree. Only A becomes aware of new work, and only A should be responsible for tracking it and reporting errors such as timeouts. B sends idempotent message(s) to A, and A updates the state, re-querying at intervals as needed.

At step 0, A becomes aware of a new request and logs it. That constitutes an obligation A must later discharge by some deadline - A will continuously perform, and repeat, the subsequent steps until A learns that request processing has completed.

Some requests will be longer than others. Estimates of processing time will become available on A and on B, perhaps revised as processing continues. Such estimates may be fed back to A so it will seldom produce false-positive timeouts. Think of it as a keep alive message that says "still working, still working".

1
source | link

Appending to a persistent log on A should suffice. This copes with reboots and network partitions to achieve eventual consistency, or to signal breakage which prevents such convergence. With amortized group commit it can take less than a single write to persist a log entry.

You suggested making B responsible for unmarking state. I disagree. Only A becomes aware of new work, and only A should be responsible for tracking it and reporting errors such as timeouts. B sends idempotent message(s) to A, an A updates the state, re-querying at intervals as needed.

At step 0, A becomes aware of a new request and logs it. That constitutes an obligation A must later discharge by some deadline - A will continuously perform, and repeat, the subsequent steps until A learns that request processing has completed.

Some requests will be longer than others. Estimates of processing time will become available on A and on B, perhaps revised as processing continues. Such estimates may be fed back to A so it will seldom produce false-positive timeouts. Think of it as a keep alive message that says "still working, still working".