Hi, Jake, why do you say the feature is not complete in 1.14.0? In my view, it works as it was designed and as documented.
I do not think it makes sense to remove a feature shipped in the 1.14.0 release that customers might already be using. If the urgent issue to solve is the unnecessary serialization overhead when the WAN or AEQ events are part of a transaction and the sender has not enabled TX batching, I propose we try to fix just this in 1.14.1. Alberto ________________________________ From: Jacob Barrett <jabarr...@vmware.com> Sent: Tuesday, September 21, 2021 11:13 PM To: dev@geode.apache.org <dev@geode.apache.org> Subject: PROPOSAL: Remove WAN TX Batching Serialization Changes Devs, In addition to my discussion regarding the modularization of the WAN TX batching implementation I would like to propose that we remove the serialization changes that went into 1.14 to support it. Since the feature is not complete in 1.14 this should only impact the associated tests in 1.14. I want to do this to eliminate the necessary serialization of the of the transaction ID and last event flags as well as the boolean to determine if there is a transaction ID. As implemented right now this data is serialized for both WAN and AEQ sender events that are part of a transaction regardless of the enablement of TX batching on the sender. The transaction ID contains both the 4 byte counter and large membership ID. https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderEventImpl.java#L712 Since this went out in 1.14.0 the removal would be treated like any other upgrade to the protocol and a 1.14.1 version would not read or write any of those bites. When talking to exactly a 1.14.0 version the implementation would write only the false flag and read the flag and ignore the rest as necessary. The tests related to TX batching would also need to be disabled. Something like this: public void toData(DataOutput out, SerializationContext context) throws IOException { // intentionally skip 1.14.0 toDataPre_GEODE_1_14_0_0(out, context); } public void toDataPre_GEODE_1_14_1_0(DataOutput out, SerializationContext context) throws IOException { toDataPre_GEODE_1_14_0_0(out, context); DataSerializer.writeBoolean(false); } public void fromData(DataInput in, DeserializationContext context) throws IOException, ClassNotFoundException { fromDataPre_GEODE_1_14_1_0(in, context); } public void fromDataPre_GEODE_1_14_1_0(DataInput in, DeserializationContext context) throws IOException, ClassNotFoundException { fromDataPre_GEODE_1_14_0_0(in, context); if (version == KnownVersion.GEODE_1_14_0.ordinal()) { if (hasTransaction) { DataSerializer.readBoolean(DataSerializer.readBoolean(in)); context.getDeserializer().readObject(in); } } } I would also propose that if 1.15.0 looks like it will ship without the modularization changes that we at least address the serialization changes here in a way that does not affect all gateways, WAN or AEQ. If accepted I will write up two JIRAs, one to address the 1.14 removal and the other as a blocker on 1.15 to address the serialization issues. Ok, chime in! -Jake
