Receiver Server and MUPIP JOURNAL ROLLBACK FETCHRESYNC reset connection on bad input
Final Release Note
When a replication Receiver Server or a MUPIP JOURNAL ROLLBACK FETCHRESYNC process waiting for a connection detects bad input, it resets the connection. Previously depending on the bad input it could fail, causing a core file, or loop producing a continuous stream of receiver server log messages taking significant amounts of file space. This was only encountered in a development environment and not reported by a user. [#676 (closed)]
Description
The v63009/gtm9134 test failed in internal testing exposing that the upstream V6.3-009 change the test is supposed to be testing did not block all spurious messages. The failures included several different asserts failing and some %YDB-E-REPLTRANS2BIG errors. The assert failures close to 50% of the time on debug builds in internal testing while the %YDB-E-REPLTRANS2BIG errors happened roughly one of out every 500 times the test was run. The test still produces these failures in newer upstream versions as of V6.3-014.
Draft Release Note
When a replication Receiver Server or a fetch resync waiting for a connection detects bad input, it resets the connection. Previously depending on the bad input it could fail, causing a core file or loop producing a continuous stream of receiver server log messages taking significant amounts of file space. This was partially fixed for replication Receiver Servers but not for fetch resyncs in V6.3-009.