Versions Compared

Key

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

...

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Currently, the `ProducerPerformance` the ProducerPerformance tool supports transactional producers but cannot randomly abort transactions during testing. This prevents developers from evaluating how transactional producers behave under failure scenarios.

...

A single new command-line option is introduced: --transaction-abort-ratio

Property
Description
Type
`
Double
`
 
Range
0.0 to 1.0 
Default
0.0 (no transactions aborted)
Dependency
Only valid when transactions are enabled
  • At `1.0`: all transactions are aborted;
  • At `0.5`: approximately half of the transactions are aborted;
  • At `0.0` (default): behavior is identical to the current version.

Proposed Changes

1. Argument parsing

...

Add the `the --transaction-abort-ratio` ratio  argument after the existing `--transaction-duration-ms` ms argument:

Code Block
languagejava
parser.addArgument("--transaction-abort-ratio")
        .action(store())
        .required(false)
        .type(Double.class)
        .metavar("TRANSACTION-ABORT-RATIO")
        .dest("transactionAbortRatio")
        .setDefault(0.0)
        .help("The ratio of transactions to abort during the test. "
                + "The value should be between 0.0 and 1.0. "
                + "This option is only valid when transactions are enabled.");


2. Configuration validation

Add a new field double transactionAbortRatio  with the following validations:

  • Throw ArgumentParserException if the value is outside the [0.0, 1.0] range;
  • Throw ArgumentParserException if transactionAbortRatio is greater than 0.0 but transactions are not enabled, since aborting without transactions is meaningless.

3. Abort logic

There are currently two places where commitTransaction() is called:

  • In-loop: when the transaction duration exceeds transactionDurationMs
  • Post-loop: to handle remaining uncommitted records

At both commit points, use the existing SplittableRandom instance to randomly decide whether to commit or abort based on the ratio:

Code Block
languagejava
if (random.nextDouble() < config.transactionAbortRatio) {
    producer.abortTransaction();
} else {
    producer.commitTransaction();
}


Note: The current code uses a fixed seed (new SplittableRandom(0)). The abort decision reuses the same instance, so for a given ratio and record count, results are deterministic and reproducible.

4. Warmup phase behavior

Transactions during the warmup phase are also subject to the --transaction-abort-ratio. The warmup phase (introduced in KAFKA-17645) is designed to bring the system into a steady state before collecting performance statistics. If the abort ratio were only applied during the steady-state phase, the system would transition from an all-commit warmup to a mixed commit/abort steady state, introducing an additional settling period that undermines the purpose of warmup. Applying the same abort ratio during warmup ensures the system has already stabilized under the target conditions when steady-state measurement beginsThis feature will add a new configuration option to the ProducerPerformance tool that allows users to specify a ratio of transactions to abort during testing. This will enable users to simulate transaction failure scenarios while measuring performance metrics.

Compatibility, Deprecation, and Migration Plan

...

  • When --transaction-abort-ratio is not specified, the tool behaves exactly as before;
  • No existing configuration options are changed or removed;
  • All existing functionality remains intact.

Test Plan

The patch will include unit tests to ensure full coverage:

...

Unit tests will cover the following scenarios:

  1. Argument parsing: Verify that --transaction-abort-ratio 0.5 is parsed correctly
  2. Range validation: Verify that values outside [0.0, 1.0] (e.g., -0.1, 1.5) throw an error
  3. Transaction dependency validation: Verify that setting a non-zero abort ratio without enabling transactions throws an error
  4. Abort logic:
    • With ratio 0.0, all transactions are committed (commitTransaction() is called)
    • With ratio 1.0, all transactions are aborted (abortTransaction() is called)
    • With intermediate ratios, verify that the number of commit and abort calls matches the expected proportion

...

Rejected Alternatives

None