[jira] [Created] (HIVE-26035) Move to directsql for ObjectStore::addPartitions

2022-03-14 Thread Rajesh Balamohan (Jira) 
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

2022-03-14 Thread Stamatis Zampetakis 
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

2022-03-14 Thread Yu Weiqiang (Jira) 
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

2022-03-14 Thread Rahul Pathak (Jira) 
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

2022-03-14 Thread Peter Vary 
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