Closed ankurcha closed 2 years ago
Use the same version of gRPC as the version of Dataflow that you are using has defined.
I am trying to use bigtable client 1.0.0-pre3 (in addition to some internal grpc services) which is compiled against grpc-java 1.5.0 is there a suggested way i can achieve using that with the dataflow sdk?
Unfortunately there are gRPC/protobuf version incompatibilities between the version you want to use and the version that Dataflow is using like this ALPN/NPN issue your running into. You might have luck trying other versions of BoringSSL or using one of the other alternative but unsupported ALPN/NPN providers for Java as well.
What would it take to change the version for grpc in the beam sdk dependency? Are we talking about incompatibilities in just the compile code level or something more on the logical side?
The Dataflow worker also uses the same version of protobuf/gRPC as Apache Beam, so even if it changed externally there would need to be the same corresponding change internally.
Unfortunately it is very hard to say whether it will work for everyone because what we have seen in the past is that generated code is version locked to the same version the protoc plugin expects so updating it breaks with runtime exceptions of UnsatisfiedLinkError or MethodNotFoundError or similar like errors. This is a better question for gRPC / protobuf folks as to the risk of using a newer gRPC/protobuf library with code that used an older version or protoc for code generation.
Seems like shading the tcnative, grpc and protobuf dependencies + setting the shaded.io.netty.packagePrefix
property is the way to get things to work.
In our latest version of a dataflow pipeline we introduced a dependency on grpc-java 1.5.0 and tcnative-boringssl
2.0.3.Final
. Running this locally with directrunner works file but on the dataflow service I get this errorThis seems to suggest that for some reason the native library is not being loaded correctly. Turning up the logging some more revealed:
Which seems to suggest some problem outside the scope of the sdk. Any suggestions on how to work around this?