[jira] [Created] (HIVE-26035) Move to directsql for ObjectStore::addPartitions
Rajesh Balamohan created HIVE-26035: --- Summary: Move to directsql for ObjectStore::addPartitions Key: HIVE-26035 URL: https://issues.apache.org/jira/browse/HIVE-26035 Project: Hive Issue Type: Bug Reporter: Rajesh Balamohan Currently {{addPartitions}} uses datanuclues and is super slow for large number of partitions. It will be good to move to direct sql. Lots of repeated SQLs can be avoided as well (e.g SDS, SERDE, TABLE_PARAMS) -- This message was sent by Atlassian Jira (v8.20.1#820001)
Re: Hive 3 and Java 11 issue
I confirm what Pau said, the only supported JDK is 8. Upgrade to JDK 11 has started [1] but was paused due to various problems. I don't know if anyone is actively working on fixing this at the moment. Best, Stamatis [1] https://issues.apache.org/jira/browse/HIVE-22415 On Thu, Mar 10, 2022 at 10:34 AM Bitfox wrote: > That sounds bad. All our apps are running on JDK 11. > > On Thu, Mar 10, 2022 at 5:06 PM Pau Tallada wrote: > >> I think only JDK8 is supported yet >> >> Missatge de Bitfox del dia dj., 10 de març 2022 a >> les 2:39: >> >>> my java version: >>> >>> openjdk version "11.0.13" 2021-10-19 >>> >>> >>> I can't run hive 3.1.2. >>> >>> The error include: >>> >>> >>> Exception in thread "main" java.lang.ClassCastException: class >>> jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to class >>> java.net.URLClassLoader (jdk.internal.loader.ClassLoaders$AppClassLoader >>> and java.net.URLClassLoader are in module java.base of loader 'bootstrap') >>> >>> >>> So I am asking Hive 3 doesn't support java 11 yet? >>> >>> >>> Thanks. >>> >> >> >> -- >> -- >> Pau Tallada Crespí >> Departament de Serveis >> Port d'Informació Científica (PIC) >> Tel: +34 93 170 2729 >> -- >> >>
[jira] [Created] (HIVE-26036) NPE caused by getMTable() in ObjectStore
Yu Weiqiang created HIVE-26036: -- Summary: NPE caused by getMTable() in ObjectStore Key: HIVE-26036 URL: https://issues.apache.org/jira/browse/HIVE-26036 Project: Hive Issue Type: Bug Components: Hive Affects Versions: 3.1.2, 4.0.0 Reporter: Yu Weiqiang Assignee: Yu Weiqiang Attachments: NPE_From_getMTable.png *Issue* Some api in ObjectStore invoke getMTable() but not check that if the returned value is null, which caused the NPE, like addPartitions(), addPartition(), alterPartition() et. *Reason* Such api described above will check that whether the table exists in HMSHandler (first check), but if the table is dropped by other threads after the first check, the NPE will happen. The simple idea is that we can check the table each time we get from getMTable(). *Stack example* !NPE_From_getMTable.png! -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (HIVE-26037) Data type mismatch in metastore upgrade for mysql upgrade-3.1.2000-to-3.1.3000.mysql.sql
Rahul Pathak created HIVE-26037: --- Summary: Data type mismatch in metastore upgrade for mysql upgrade-3.1.2000-to-3.1.3000.mysql.sql Key: HIVE-26037 URL: https://issues.apache.org/jira/browse/HIVE-26037 Project: Hive Issue Type: Bug Reporter: Rahul Pathak Below error was notice while doing upgrade of hive metadata using mysql setup Referencing column 'ACTIVE_EXECUTION_ID' and referenced column 'SCHEDULED_EXECUTION_ID' in foreign key constraint 'SCHEDULED_EXECUTIONS_SCHQ_ACTIVE' are incompatible. I can see below inconsistencies. {code:java} upgrade-3.1.2000-to-3.1.3000.mysql.sql: SCHEDULED_EXECUTION_ID BIGINT NOT NULL{code} {code:java} upgrade-3.1.3000.7.1.0.0-to-3.1.3000.7.1.1.0.mysql.sql:ALTER TABLE SCHEDULED_QUERIES ADD COLUMN ACTIVE_EXECUTION_ID INTEGER ;{code} -- This message was sent by Atlassian Jira (v8.20.1#820001)
Failing tests
If I remember correctly the decision was to not to merge changes with failing PreCommit tests. Lately, because of a mistake where the change was only partially merged, we had a failing test. I have tried to fix this issue and confirm it by rerunning the tests, but the check failed again. Now it failed with some different tests, because in the meantime there were some more failing tests were committed to master in the meantime. I think it would be good to stick to the previous decision and we should only commit changes if all of the tests are green. Also if there are some issues then it would be good to take the time to fix the failures or revert the changes causing the issues. Thanks, Peter