Github user StephanEwen commented on the issue:

    https://github.com/apache/flink/pull/4943
  
    I updated this PR with the following proposed solution:
    
      1. Avro is always part of the user code space, and hence will be loaded 
into the user code classloader. This solves multiple problems:
         - It allows users to use a different Avro version compared to the 
version in a spoiled classpath (for example when Hadoop depenencies pull in 
another Avro version).
         - It means that Avro class and schema caching is done per user code 
classloader, not JVM wide. That prevents "X cannot be cast to X" exceptions.
    
      2. By default, a new pure Avro serializer is used for Avro types (in 
flight and in state). Since Avro class format changed, having compatibility 
activated by default is not possible anyways.
    
      3. If a user wants to recover an old savepoint that happend to have Avro 
types serialized as PoJos, they need to do the following;
         - Set the Avro version to the same version that they had when creating 
the savepoint. Since Avro now lives in user code space, that is possible 
without changing/rebuilding Flink.
         - Pass a Flag to the `AvroTypeInfo` to use a backwards compatible 
Serializer: `new AvroTypeInfo(myType, true)`.


---

Reply via email to