[ https://issues.apache.org/jira/browse/BEAM-9144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17020387#comment-17020387 ]
Aaron Dixon commented on BEAM-9144: ----------------------------------- [~suztomo] If it helps I'm attaching the portion of my Dataflow startup logs (which include the exception). [^dataflow_step_job_id_OBFUSC-0.json] An interesting segment of the log shows the Java command that starts the worker. You can see my packaged JAR in the classpath but also the Dataflow runner-framework JARs `/opt/google/dataflow/streaming/libWindmillServer.jar` and `/opt/google/dataflow/streaming/dataflow-worker.jar` -- I suspect the classes within these Dataflow system JARs are affecting the load of the old protobuf versions. (Hope this helps.) {noformat} "Executing: java -Xmx5959858421 -XX:-OmitStackTraceInFastThrow -Xloggc:/var/log/dataflow/jvm-gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=2 -XX:GCLogFileSize=512K -cp /opt/google/dataflow/streaming/libWindmillServer.jar:/opt/google/dataflow/streaming/dataflow-worker.jar:/opt/google/dataflow/slf4j/jcl_over_slf4j.jar:/opt/google/dataflow/slf4j/log4j_over_slf4j.jar:/opt/google/dataflow/slf4j/log4j_to_slf4j.jar:/var/opt/google/dataflow/**ARTIFACT_MISC-DISGUISED**-0.1.0-SNAPSHOT-standalone-Eat01V3rIGIwd4f4ctrF_w.jar -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=5555 -Dcom.sun.management.jmxremote.rmi.port=5555 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote=true -Ddataflow.worker.json.logging.location=/var/log/dataflow/dataflow.json.log -Ddataflow.worker.logging.filepath=/var/log/dataflow/dataflow-json.log -Ddataflow.worker.logging.location=/var/log/dataflow/dataflow-worker.log -Djava.rmi.server.hostname=localhost -Djava.security.properties=/opt/google/dataflow/tls/disable_gcm.properties -Djob_id=2020-01-20_08_13_54-12155510520957136076 -Dsdk_pipeline_options_file=/var/opt/google/dataflow/pipeline_options.json -Dstatus_port=8081 -Dwindmill.hostport=tcp://**JOB_NAME-DISGUISED**1579536-01200813-7s1g-harness-r5j8:12346 -Dworker_id=**JOB_NAME-DISGUISED**1579536-01200813-7s1g-harness-r5j8 org.apache.beam.runners.dataflow.worker.StreamingDataflowWorker" {noformat} > Beam's own Avro TimeConversion class in beam-sdk-java-core > ----------------------------------------------------------- > > Key: BEAM-9144 > URL: https://issues.apache.org/jira/browse/BEAM-9144 > Project: Beam > Issue Type: Bug > Components: sdk-java-core > Reporter: Tomo Suzuki > Assignee: Tomo Suzuki > Priority: Major > Fix For: 2.19.0 > > Attachments: avro-beam-dependency-graph.png, > dataflow_step_job_id_OBFUSC-0.json > > Time Spent: 2h 10m > Remaining Estimate: 0h > > From Aaron's comment in > https://issues.apache.org/jira/browse/BEAM-8388?focusedCommentId=17016476&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17016476 > . > {quote}My org must use Avro 1.9.x (due to some Avro schema resolution issues > resolved in 1.9.x) so downgrading Avro is not possible for us. > Beam 2.16.0 is compatible with our usage of Avro 1.9.x – but upgrading to > 2.17.0 we are broken as 2.17.0 links to Java classes in Avro 1.8.x that are > not available in 1.9.x. > {quote} > The Java class is > {{org.apache.avro.data.TimeConversions.TimestampConversion}} in Avro 1.8. > It's renamed to {{org.apache.avro.data.JodaTimeConversions}} in Avro 1.9. > h1. Beam Java SDK cannot upgrade Avro to 1.9 > Beam has Spark runners and Spark has not yet upgraded to Avro 1.9. > Illustration of the dependency > !avro-beam-dependency-graph.png|width=799,height=385! > h1. Short-term Solution > As illustrated above, as long as Beam Java SDK uses only the intersection of > Avro classes, method, and fields between Avro 1.8 and 1.9, it will provide > flexibility in runtime Avro versions (as it did until Beam 2.16). > h2. Difference of the TimeConversion Classes > Avro 1.9's TimestampConversion overrides {{getRecommendedSchema}} method. > Details below: > Avro 1.8's TimeConversions.TimestampConversion: > {code:java} > public static class TimestampConversion extends Conversion<DateTime> { > @Override > public Class<DateTime> getConvertedType() { > return DateTime.class; > } > @Override > public String getLogicalTypeName() { > return "timestamp-millis"; > } > @Override > public DateTime fromLong(Long millisFromEpoch, Schema schema, LogicalType > type) { > return new DateTime(millisFromEpoch, DateTimeZone.UTC); > } > @Override > public Long toLong(DateTime timestamp, Schema schema, LogicalType type) { > return timestamp.getMillis(); > } > } > {code} > Avro 1.9's JodaTimeConversions.TimestampConversion: > {code:java} > public static class TimestampConversion extends Conversion<DateTime> { > @Override > public Class<DateTime> getConvertedType() { > return DateTime.class; > } > @Override > public String getLogicalTypeName() { > return "timestamp-millis"; > } > @Override > public DateTime fromLong(Long millisFromEpoch, Schema schema, LogicalType > type) { > return new DateTime(millisFromEpoch, DateTimeZone.UTC); > } > @Override > public Long toLong(DateTime timestamp, Schema schema, LogicalType type) { > return timestamp.getMillis(); > } > @Override > public Schema getRecommendedSchema() { > return > LogicalTypes.timestampMillis().addToSchema(Schema.create(Schema.Type.LONG)); > } > } > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)