Stratara 4.6.1

A release about two costs of the Orleans execution model that grew with the deployment rather than with the work.

A commit woke every projection and saga reader of each partition it touched, whatever it had committed. Every one of
them read the new entries and wrote its checkpoint, also when it applied nothing, and every reader polled the store on
its own: every single-event command cost a checkpoint write per projection and saga, and an idle silo with many
consumers kept the store busy with hundreds of reads a second. A commit now costs work only for the readers it
concerns, and an idle silo asks the store a few questions per partition and poll interval.

A recorded command whose handler met a concurrency conflict waited for its hand-over to lapse, 30 seconds by default,
before the drain ran it again; on the bus a conflicting message is redelivered at once. It now runs again within
moments.

Added

• ProjectionGrainOptions.IdleCheckpointInterval (default 30 seconds) bounds how long a projection's reader may
  hold its checkpoint back past entries it applied nothing for. TimeSpan.Zero writes the checkpoint after every
  batch, as before.
• ICommandIntentStore.CountConflictAsync counts a conflict and records it without giving the attempt back, and
  answers how many conflicts the command has met. The default records through RecordConflictAsync and answers
  null, so an intent store of your own compiles and behaves as before; the framework's store implements it.

Changed

• A commit wakes only the readers whose projection or saga applies one of its event types. This holds for the
  wake-up on a silo with a store-reading role and for AddStrataraStoreWakeUps(). Woken by every commit as before:
  a stateful saga process, which decides from the event itself, and every reader when the commit holds an event type
  the silo cannot resolve or whose upcaster refuses an empty payload, or when the host's upcaster pipeline is its own.
  A multi-stream commit wakes, in each partition, the readers of the events it wrote there. In a test host with six
  projections of which one applied the commit, ten commits cost 59 store reads before and only the applying
  projection's reads now, and a commit nobody applies costs no read when it is made. A reader whose partition moved
  past it still reads once at its next poll, and then waits again.
• A projection's reader writes its checkpoint past entries it applied nothing for later: with the next batch that
  applies something, once IdleCheckpointInterval has passed, or when it deactivates. It answers waits for its
  projection from the position it holds. A reader whose silo dies before the write reads those entries again and
  applies nothing for them. A rebuild or a replay discards a position held back. A saga's reader writes its checkpoint
  after every batch as before, because a saga added to a running deployment starts where the host's sagas have
  written they read.
• A poll reads the store only when its partition holds something past the reader's position. Each silo asks the
  store for a partition's head at most once per half poll interval, for all its readers. In the test host, 96 idle
  readers polling every 500 ms read the store about 960 times in five seconds before and not at all now. A lost
  wake-up is applied within about one and a half poll intervals rather than one. A committed position reader that
  does not override ICommittedPositionReader.HeadAsync keeps polling as before.
• A conflicting recorded command runs again at once. The silo that ran it runs it again in a unit of work of its
  own while it still holds the hand-over, pausing as the ResilienceNames.ConcurrencyConflict pipeline does (five
  retries from 50 ms), on the aggregate activation's scheduler. A heavy command keeps its permit. Every conflict is
  still recorded and counted, and the command runs again only while its conflicts stay within
  MessageRetryOptions.MaxConflictRequeues, so a command that conflicts on every attempt runs as often as before and
  is kept. The hand-over's attempt is given back once when the command leaves on a conflict, however often it ran.
  After the pipeline's retries the drain resumes it as before.
• ExecutionModelTestHost.WaitForReadersAsync waits for the readers' positions, not their stored checkpoints,
  so it returns once every reader has read to the head, whether or not it has written its checkpoint there yet.

Upgrading: nothing to do. Hosts and silos of 4.6.0 and of this release mix in a rolling deployment: the cluster
wake-up keeps its form, an earlier host's wake-up wakes every reader, and an earlier silo wakes every reader of a newer
host's wake-up. Checkpoints keep their form. An intent store of your own keeps the old timing after a conflict until
it implements CountConflictAsync.