Hi Mahima, have you checked whether the problematic dependency (seems to be avro) is contained in Flink's /lib folder in your case? I would suggest to check on JobManagers and TaskManagers, since you say it's in the business logic.
Have you tried the suggestions mentioned in the docs? Those would be: - Either make sure the dependency is only contained in the jar of your job, and *not* in the Flink /lib folder - Or make sure you do not use dynamic classloading at all - Or try disabling inverted classloading to see if this changes something - Or shade away the dependency I don't have experience with Avro caching behavior; the first two suggestions are probably more relevant there, according to the docs. Best, Nico On Fri, Mar 25, 2022 at 5:22 AM Mahima Agarwal <mahi.29agar...@gmail.com> wrote: > Hi Team, > > Just a follow up mail regarding the query. > > Any leads would be appreciated. > > Thanks and Regards > Mahima Agarwal > > > > On Mon, Mar 21, 2022 at 2:56 PM Mahima Agarwal <mahi.29agar...@gmail.com> > wrote: > >> Hi Team, >> >> I am getting a ClassCastException in my flink job's business logic when >> using the below code to clone an object with newBuilder. >> >> MyClass outEvent = new MyClass(); >> outEvent = (MyClass) MyClass.newBuilder(inEvent).build(); >> >> Exception : Caused by: java.lang.ClassCastException: >> com.avro.mon.nfConsumerIdentification cannot be cast to >> com.avro.mon.nfConsumerIdentification >> >> Also, In Flink documention I found a description of similar problem - >> https://nightlies.apache.org/flink/flink-docs-release-1.14/docs/ops/debugging/debugging_classloading/#x-cannot-be-cast-to-x-exceptions >> >> But, as per the solution mentioned in the document we could not package >> the avro jar in the job, we can only add the avro jar to the Flink /lib >> folder. >> >> Is there any way we can clear the cache in Avro or any other way we can >> solve this? >> >> Any leads would be appreciated. >> >> Thanks and Regards >> Mahima Agarwal >> >
