Our bug kept us from seeing the results of DESCRIBE/SHOW/etc. but I'll ask the client if they can run it and report the results. That definitely sounds like something we can use in the future.
Thanks On Wed, Aug 16, 2017 at 2:59 AM, Furcy Pin <furcy....@flaminem.com> wrote: > Hi Giles, > > Did you try running the query with the EXPLAIN AUTHORIZATION clause? > > https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Explain# > LanguageManualExplain-TheAUTHORIZATIONClause > > On Wed, Aug 16, 2017 at 3:08 AM, Bear Giles <bgi...@snaplogic.com> wrote: > >> Hi, an issue came up during recent AT and I'm hoping someone will have >> ideas on how we can check for this in the future, esp. if we can automate >> it somehow. >> >> In this case we had a client using our Hive client in the existing >> release without problems. When they copied their process to the UAT system >> for the final User Acceptance Testing it failed and they reported it as a >> defect in our pending release. >> >> I looked at it - when I ran the query I got a generic SQL Exception >> message. (If there were further details we didn't capture them.) It >> consistently took about 20 minutes to get the error. I simplified the query >> repeatedly in order to reduce the number of unknowns but it was always a >> generic SQL Exception that took about 20 minutes... except for the one time >> it took 4 hours(!). >> >> However we had a valid connection. I could execute 'select 1 as x' and >> get an immediate response. (Maybe 20s, but "immediate" when you've been >> waiting 20 minutes or more.) Clearly I didn't have bad credentials. >> >> I tried running DESCRIBE table and SHOW tables but didn't get anything >> useful due to a bug in our software - we're treating those as a statement >> instead of a query so I didn't get anything useful. I couldn't push a fix >> either since we were in UAT and the other machines weren't whitelisted to >> access their servers. >> >> I made an informed guess that it could be a permissions issue with the >> underlying tables and they should check that. Nothing else made sense - we >> were clearly establishing a connection and the only difference between >> production and UAT was the host running the software. The customer was >> skeptical but eventually double-checked the connection properties and >> permissions and determined that there was a difference between the systems. >> I don't know what the ultimate problem was. I'm pretty sure it wasn't just >> a different account that didn't have the table - IIRC I did a test where I >> tried to select records from a non-existent table and it returned quickly >> with a meaningful error. >> >> My questions: >> >> 1. What conditions could result in the ability to establish a connection, >> run a query such as 'select 1 as x', but take 20 minutes to throw an error >> when I run a query like 'select guid from foo limit 1'? >> >> 2. How can I test for them? Now that we're post-UAT (and this is a known >> concern) we can add logic to perform standard tests for missing permissions >> if we know what to do. >> >> Thanks. >> >> >> Bear Giles >> >> Sr. Java Application Engineer >> bgi...@snaplogic.com >> Mobile: 720-749-7876 <(720)%20749-7876> >> >> >> <http://www.snaplogic.com/about-us/jobs> >> >> >> >> *SnapLogic Inc | 929 Pearl St #200 | 80303 CO 80302 | USA* >> >> *SnapLogic Inc | 2 W 5th Avenue 4th Floor | San Mateo CA 94402 | USA * >> >> >> This message is confidential. It may also be privileged or otherwise >> protected by work product immunity or other legal rules. If you have >> received it by mistake, please let us know by e-mail reply and delete it >> from your system; you may not copy this message or disclose its contents to >> anyone. The integrity and security of this message cannot be guaranteed on >> the Internet. >> > > -- Bear Giles Sr. Java Application Engineer bgi...@snaplogic.com Mobile: 720-749-7876 <http://www.snaplogic.com/about-us/jobs> *SnapLogic Inc | 929 Pearl St #200 | 80303 CO 80302 | USA* *SnapLogic Inc | 2 W 5th Avenue 4th Floor | San Mateo CA 94402 | USA * This message is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. The integrity and security of this message cannot be guaranteed on the Internet.
