Danny Chan

> Not very persuaded by the improvement number: read 33% and write 9%, if the number is real and can be re-productive, i would suggest to lower priority of the...

> This change is very critical first step in that direction of decoupling Hudi fro Avro I agree we should decouple Hudi from Avro, but that does not mean we...

> I don't think we are aligned on this one: Hudi is and will be staying engine-neutral project. However for the top-of-the-line performance on _any_ engine (to stay competitive with...

+1, but i guess the community is too busy to do that right now, maybe we can do that after release 1.0.0.

If the end commit is active and is used as the filtering instant for scan, shouldn't `getLatestFileSliceBeforeOrOn` work here ?

> > If the end commit is active and is used as the filtering instant for scan, shouldn't `getLatestFileSliceBeforeOrOn` work here ? > > yes, it works, but it can't...

Hmm, 0.11 is a very old release, can you show some logs in JM to enlight some clues of the scheduling process?

Okay, is there any way you can upgrade your Hudi release to 0.14.1?

Looks like a jackson jar conflict.

Finds out where the legacy jackson comes from and remove it from the classpath.