...

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

Motivation

There are no official tools available to measure the performance of aborted transactions. The ProducerPerformance tool currently Currently, the ProducerPerformance tool supports transactional producers but lacks the ability to cannot randomly abort transactions during testing. This limitation prevents users developers from properly evaluating how transactional producers behave when transactions are aborted, which is important for production systems where transaction failures can occur.

The ability to test aborted transactions is crucial for:

under failure scenarios.

This proposal targets four critical areas:

1. Measuring the overhead costs of aborting transactions;
2. Assessing how failed transactions affect
3. Understanding the overhead associated with transaction abortion;
4. Evaluating the performance impact of failed transactions on producer throughput;
5. Validating transaction recovery mechanismsprocesses;
6. Benchmarking transactional producers under realistic failure scenariosfault conditions.

Public Interfaces

New Configuration Option:
  A single new command-line option is introduced: --transaction-abort-ratio: Ratio of transactions to abort (

...

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
;
• When set to 1.0, all transactions will be aborted;
• When set to 0.5, half of the transactions will be are aborted;
• At `0.0` (default): behavior is identical to the current version.

Proposed Changes

1. Argument parsing

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

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:

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