1.47.2

Known issues

• [Java] ClusterBackup might connect to two different Cluster nodes simultaneously whereby one is used to provide the live Raft log replay and to download the snapshots, whereas the other one is used to fetch the latest list of snapshot entries and the recording log metadata. As long as all of the Cluster nodes are "in sync" (i.e. have the same set of snapshots) then everything is ok. However, if the second node from which ClusterBackup fetches the snapshots was down for some time (i.e. does not have all of the snapshots) then the ClusterBackup might end up with a broken recording log whereby recording log entries will have a different log position to the underlying snapshot recordings.
  Fixed in 1.47.3

Changelog

• [Java] Fix a regression in AeronArchive#listRecording which could return arbitrary recording information when the specified recordingId is not found (does not exist or state is not VALID) instead of sending back ControlResponseCode.RECORDING_UNKNOWN.
• [C] Apply aeron.conductor.cpu.affinity to the thead in SHARED threading mode and aeron.sender.cpu.affinity to sender/receiver thread in SHARED_NETWORK threading mode.
• [C] Add support for setting CPU affinity for the async executor thread (aeron.driver.async.executor.cpu.affinity property and AERON_DRIVER_ASYNC_EXECUTOR_CPU_AFFINITY env variable).