Hi Gopal, Thanks for taking a look, and for the workaround suggestion.
Your workaround worked for the original SerDe we encountered this issue with. With the stub StorageHandler mentioned above it produced a different error (https://pastebin.com/iu0hh21C). But I suspect that's a problem with the StorageHandler being a bit *too* minimal. I'll see if I can't correct that later today. Thanks again, Jason On Thu, Sep 13, 2018 at 10:13 PM Gopal Vijayaraghavan <gop...@apache.org> wrote: > > Hi, > > > Hopefully someone can tell me if this is a bug, expected behavior, or > > something I'm causing myself :) > > I don't think this is expected behaviour, but where the bug is what I'm > looking into. > > > We have a custom StorageHandler that we're updating from Hive 1.2.1 to > > Hive 3.0.0. > > Most likely this bug existed in Hive 1.2 as well, but the FetchTask > conversion did not happen for these queries. > > I'll probably test out your SerDe tomorrow, but I have two target cases to > look into right now. > > The first one is that this is related to a different issue I noticed with > Hadoop-Common code (i.e a direct leak). > > https://issues.apache.org/jira/browse/HADOOP-10513 > > The second one is that this is only broken with the Local FetchTask (which > gets triggered when you run "select ... limit n"). > > > SELECT * FROM my_ext_table; > > So those theories, I recommend trying out > > set hive.fetch.task.conversion=none; > > and running the same query so that the old Hive1 codepaths for reading from > the SerDe get triggered. > > Cheers, > Gopal > >
