[BEAM-8676] Upgrade gax-java 1.60.0 and grpc 1.32.2

[veblush]

gRPC 1.32.2 has two important changes;

• Conscrypt-related optimization in the ALTS protocol
• BDP-estimator fix

R: @suztomo @lukecwik

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Choose reviewer(s) and mention them in a comment (R: @username).
• Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

Post-Commit Tests Status (on master branch)

Lang	SDK	Dataflow	Flink	Samza	Spark	Twister2
Go		---		---		---
Java
Python				---		---
XLang		---		---		---

Pre-Commit Tests Status (on master branch)

---	Java	Python	Go	Website	Whitespace	Typescript
Non-portable
Portable	---		---	---	---	---

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

[lukecwik]

#13075 is working on using the GCP libraries BOM within Beam to manage deps. It would be preferable if that change made it in first and we updated the libraries BOM version to one containing grpc 1.32.2 instead of doing these one off changes.

[veblush]

@lukecwik Oh having the bom would be nicer. As long as I can get this upgrade in Beam 2.26, I'm fine with both approaches. Do you think it will happen in Nov 4?

[lukecwik]

@lukecwik Oh having the bom would be nicer. As long as I can get this upgrade in Beam 2.26, I'm fine with both approaches. Do you think it will happen in Nov 4?

@kileys

[kileys]

I should be able to get in the BOM changes before Nov 4th. Do you know when the libraries bom update will be released?

[lukecwik]

I should be able to get in the BOM changes before Nov 4th. Do you know when the libraries bom update will be released?

12.1.0 has already been released containing the updated gRPC instance.

[kennknowles]

We can merge this while we are getting ready for the change to the BOM.

[kennknowles]

Run Java PreCommit

[kennknowles]

Run Python_PVR_Flink PreCommit

[kennknowles]

Run Portable_Python PreCommit

[kennknowles]

Some of the failures looked potentially real, in tests that have not flaked previously.

[veblush]

I guess Java test has real failures. (I don't think Python_PVR_Flink is relevant to this PR)

There are two tests failing. I guess this is coming from protobuf upgrading to 3.12 (from 3.11.1)

• ProtoDynamicMessageSchemaTest.testNestedRowToProto
• ProtoDynamicMessageSchemaTest.testMapRowToProto

Because I don't think protobuf introduced actual breaking changes so I took a look at these test code,

  @Test
  public void testNestedRowToProto() throws InvalidProtocolBufferException {
    ProtoDynamicMessageSchema schemaProvider = schemaFromDescriptor(Nested.getDescriptor());
    SerializableFunction<Row, DynamicMessage> fromRow = schemaProvider.getFromRowFunction();
    // equality doesn't work between dynamic messages and other,
    // so we compare string representation
    assertEquals(NESTED_PROTO.toString(), fromRow.apply(NESTED_ROW).toString());
  }

The error message is like below.

org.junit.ComparisonFailure: expected:<...sted_map {
  key: "k[1"
  value {
    primitive_double: 1.1
    primitive_float: 2.2
    primitive_int32: 32
    primitive_int64: 64
    primitive_uint32: 33
    primitive_uint64: 65
    primitive_sint32: 123
    primitive_sint64: 124
    primitive_fixed32: 30
    primitive_fixed64: 62
    primitive_sfixed32: 31
    primitive_sfixed64: 63
    primitive_bool: true
    primitive_string: "horsey"
    primitive_bytes: "\001\002\003\004"
  }
}
nested_map {
  key: "k2]"
  value {
    prim...> but was:<...sted_map {
  key: "k[2"
  value {
    primitive_double: 1.1
    primitive_float: 2.2
    primitive_int32: 32
    primitive_int64: 64
    primitive_uint32: 33
    primitive_uint64: 65
    primitive_sint32: 123
    primitive_sint64: 124
    primitive_fixed32: 30
    primitive_fixed64: 62
    primitive_sfixed32: 31
    primitive_sfixed64: 63
    primitive_bool: true
    primitive_string: "horsey"
    primitive_bytes: "\001\002\003\004"
  }
}
nested_map {
  key: "k1]"
  value {
    prim...>

From the code & output reading, it might be caused by using string comparison to compare two objects but chances are that two strings are not normalized, which could cause them to fail. (it's my wild guess)

@alexvanboxel, @reuvenlax
I want help from original author and review on #10502.

[kennknowles]

Note that the Python tests are Python-on-Flink so they do touch a number of Beam libraries. I think you are probably right that they are not actually affected, but do not let the name fool you.

[kennknowles]

Agree with your assessment. These tests are written in a fragile way. The strings should not be normalized, but just test the equality directly in a robust way.

[veblush]

@kennknowles I addressed the issue of the test. PTAL.

[kennknowles]

Thanks for hardening the test! The results are green and look good. The commit history is clean. Thanks a bunch!