[KAFKA-9950] MirrorMaker2 sharing of ConfigDef can lead to ConcurrentModificationException

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.4.0, 2.5.0, 2.4.1
• Fix Version/s: 2.6.0, 2.4.2, 2.5.1
• Component/s: mirrormaker
• Assignee: Chris Egerton
• Reporter: Chris Egerton
• Created: 04/May/20 04:35
• Updated: 21/May/20 04:22
• Resolved: 21/May/20 04:22

Description

The MirrorConnectorConfig::CONNECTOR_CONFIG_DEF object is reused across multiple MirrorMaker2 classes, which is fine the most part since it's a constant. However, the actual ConfigDef object itself is mutable, and is mutated when the MirrorTaskConfig class statically constructs its own ConfigDef.

This has two unintended effects:

1. Since the two ConfigDef objects for the MirrorConnectorConfig and MirrorTaskConfig classes are actually the same object, the additional properties that the MirrorTaskConfig class defines for its ConfigDef are also added to the MirrorConnectorConfig class's ConfigDef. The impact of this isn't huge since both additional properties have default values, but this does cause those properties to appear in the /connectors/{name}/config/validate endpoint once the MirrorTaskConfig class is loaded for the first time.
2. It's possible that, if a config for a MirrorMaker2 connector is submitted at approximately the same time that the MirrorTaskConfig class is loaded, a ConcurrentModificationException will be thrown by the AbstractHerder class when it tries to iterate over all of the keys of the connector's ConfigDef.

Issue Links

• links to: GitHub Pull Request #8608