Versions Compared

Old Version 4

changes.mady.by.user Sumant Tambe

Saved on

compared with

New Version 5

changes.mady.by.user Sumant Tambe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Compatibility, Deprecation, and Migration Plan

Path to support Support the current behavior via batch.expiry.ms default values
  1. When max.in.flight.request.per.connection==1: batch.expiry.ms=MAX_LONG. Batches will stay in the accumulator as long as progress is being made. Will ensure expiration is also in - order.
  2. When max.in.flight.request.per.connection > 1: delivery and notification ordering is not needed/provided. batch.expiry.ms=request.timeout.ms. Batches may expire out of order. As batch.expiry.ms will be set dynamically (if not provided explicitly) based on the above settings. 
As a consequence, batch expiration delay is coupled with strict ordering is desired or not. This correlation is not obvious but makes sense eventually. In case of guaranteed ordering, head-of-the-line blocking may arbitrarily delay expiration of batches far back in the queue. 

Validation

This configuration is backwards compatible. TODO: Consider various combinations of timeouts that don't make sense. (E.g., batch.expiry.ms < linger.ms).

...