Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.8.0
Description
In one of our production pipelines, we have a table with 1200+ columns. At runtime, it failed due to a method inside the generated code exceeding 64kb when compiled to bytecode.
After we investigated the generated code, it appeared that the map method inside a generated RichMapFunction was too long. See attached file (codegen.example.txt).
In the problematic map method, result setters were correctly split into individual methods and did not have the largest footprint.
However, there were also 1000+ input unboxing expressions inside reusableInputUnboxingExprs, which, individually were not trivial and when flattened linearly in the map function here, pushed the method size beyond 64kb in bytecode.
We think it is worthwhile to split these input unboxing code snippets into individual methods. We were able to verify, in our production environment, that splitting input unboxing code snippets into individual methods resolves the issue. Would love to hear thoughts from the team and find the best path to fix it.
