[jira] [Updated] (KUDU-1661) Mark kudu::client::KuduClient::GetLatestObservedTimestamp() as experimental
[ https://issues.apache.org/jira/browse/KUDU-1661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Serbin updated KUDU-1661: Status: In Review (was: In Progress) > Mark kudu::client::KuduClient::GetLatestObservedTimestamp() as experimental > --- > > Key: KUDU-1661 > URL: https://issues.apache.org/jira/browse/KUDU-1661 > Project: Kudu > Issue Type: Improvement > Components: api, client, documentation >Affects Versions: 1.0.0 >Reporter: Alexey Serbin >Assignee: Alexey Serbin >Priority: Minor > > Per [~dr-alves], the kudu::client::KuduClient::GetLatestObservedTimestamp() > method of the Kudu client C++ API is about to change its signature soon to > return just an opaque sequence of bytes. So, it should be marked as > experimental to inform the users of the current API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KUDU-1653) Python 3 Failing to decode serialized token
[ https://issues.apache.org/jira/browse/KUDU-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan Birdsell updated KUDU-1653: -- Resolution: Fixed Fix Version/s: 1.1.0 Status: Resolved (was: In Review) Commit 1c4dcabddc1188e0881d6b35141cee1ec7171e7b > Python 3 Failing to decode serialized token > --- > > Key: KUDU-1653 > URL: https://issues.apache.org/jira/browse/KUDU-1653 > Project: Kudu > Issue Type: Bug > Components: python >Affects Versions: 1.1.0 >Reporter: Jordan Birdsell >Assignee: Jordan Birdsell > Fix For: 1.1.0 > > > Python 3 attempts to deserialize token into utf-8 string and causes failure: > UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 141: > invalid start byte -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KUDU-1652) Partition pruning / scan optimization fails with IS NOT NULL predicate on PK column
[
https://issues.apache.org/jira/browse/KUDU-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Burkert updated KUDU-1652:
--
Description: Both the Java client and C++ client/server currently have a
bug where attempting a scan with an {{IS NOT NULL}} predicate on a primary key
column can throw an exception (Java), or crash the C++ client or server. This
is a rare situation currently since {{IS NOT NULL}} is not publicly accessible,
so it has to come from a simplified predicate like {{my_int8_column <= 127}}.
The fix is straightforward: stop encoding the lower/upper bound keys when an
{{IS NOT NULL}} predicate is encountered. (was: Both the Java client and C++
client/server currently have a bug where attempting a scan with an {{IS NOT
NULL}} predicate on a primary key column can through an exception (Java), or
crash the C++ client or server. This is a rare situation currently since {{IS
NOT NULL}} is not publicly accessible, so it has to come from a simplified
predicate like {{my_int8_column <= 127}}. The fix is straightforward: stop
encoding the lower/upper bound keys when an {{IS NOT NULL}} predicate is
encountered.)
> Partition pruning / scan optimization fails with IS NOT NULL predicate on PK
> column
> ---
>
> Key: KUDU-1652
> URL: https://issues.apache.org/jira/browse/KUDU-1652
> Project: Kudu
> Issue Type: Sub-task
> Components: client, tablet
>Affects Versions: 1.0.0
>Reporter: Dan Burkert
>Assignee: Dan Burkert
>Priority: Blocker
> Fix For: 1.0.0, 1.0.1
>
>
> Both the Java client and C++ client/server currently have a bug where
> attempting a scan with an {{IS NOT NULL}} predicate on a primary key column
> can throw an exception (Java), or crash the C++ client or server. This is a
> rare situation currently since {{IS NOT NULL}} is not publicly accessible, so
> it has to come from a simplified predicate like {{my_int8_column <= 127}}.
> The fix is straightforward: stop encoding the lower/upper bound keys when an
> {{IS NOT NULL}} predicate is encountered.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KUDU-1666) filter IS NOT NULL predicates on non-nullable columns from scans in client
Dan Burkert created KUDU-1666:
-
Summary: filter IS NOT NULL predicates on non-nullable columns
from scans in client
Key: KUDU-1666
URL: https://issues.apache.org/jira/browse/KUDU-1666
Project: Kudu
Issue Type: Bug
Components: client
Affects Versions: 1.0.0
Reporter: Dan Burkert
Priority: Blocker
Kudu 1.0.0 has a bug (KUDU-1651) that causes the tablet server to crash when a
scan includes an {{IS NOT NULL}} predicate on a non-nullable column. To avoid
hitting this bug if applications update their client but not their server, we
should filter these predicates on the client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KUDU-1662) Kudu fs command reports permission denied
[
https://issues.apache.org/jira/browse/KUDU-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15534093#comment-15534093
]
Adar Dembo commented on KUDU-1662:
--
I thought these permissions result from a restrictive umask belonging to the
user in question. But, they actually stem from how Kudu creates the files. Kudu
never specifically changes file permisson, but all new files are created with
0644, except for files that begin as tmpfiles and are renamed into place; those
are implicitly created as 0600. The instance files mentioned in the description
are tmpfiles. So, when we create those files, we could immediately fchmod()
them to 0644. Though we'd have to be careful; if we actually _did_ want a
secure temporary file, 0600 is obviously what we'd want.
The warning about "proceeding without a lock" when using root is to be
expected; yes, you're running a read-only tool, but the files in question are
actively in use by a running Kudu master.
> Kudu fs command reports permission denied
> -
>
> Key: KUDU-1662
> URL: https://issues.apache.org/jira/browse/KUDU-1662
> Project: Kudu
> Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: 1. Kudu demo Quickstart VM (VirtualBox) running CDH 5.8
> 2. New Kudu (VMWare) VM running CDH 5.8 in Centos 6.6. with Kudu installed
> from command line (no CM)
>Reporter: Suzanne McIntosh
>Priority: Minor
>
> This is a minor issue because the uuid is ultimately displayed.
> Issuing 'kudu fs dump uuid ...' gives a permission denied error as shown
> below. Testing against the Kudu demo VM yielded the same result. Using sudo
> gives a different error.
> My session below shows results of using plain kudu command, followed by an
> attempt to clear the permission denied message by using sudo:
>
> {code}
> [training@localhost ~]$ kudu fs dump uuid -fs_wal_dir /var/lib/kudu/master
> -fs_data_dirs /var/lib/kudu/master
> I0929 14:57:30.706712 6436 mem_tracker.cc:140] MemTracker: hard memory limit
> is 4.673157 GB
> I0929 14:57:30.706782 6436 mem_tracker.cc:142] MemTracker: soft memory limit
> is 2.803894 GB
> IO error: /var/lib/kudu/master/instance: Permission denied (error 13)
> [training@localhost ~]$ sudo kudu fs dump uuid -fs_wal_dir
> /var/lib/kudu/master -fs_data_dirs /var/lib/kudu/master
> I0929 14:57:44.155582 6448 mem_tracker.cc:140] MemTracker: hard memory limit
> is 4.673157 GB
> I0929 14:57:44.155685 6448 mem_tracker.cc:142] MemTracker: soft memory limit
> is 2.803894 GB
> W0929 14:57:44.157841 6450 log_block_manager.cc:1616] IO error: Could not
> lock /var/lib/kudu/master/data/block_manager_instance: Could not lock
> /var/lib/kudu/master/data/block_manager_instance: lock
> /var/lib/kudu/master/data/block_manager_instance: Resource temporarily
> unavailable (error 11)
> W0929 14:57:44.157857 6450 log_block_manager.cc:1617] Proceeding without lock
> I0929 14:57:44.158095 6448 fs_manager.cc:243] Opened local filesystem:
> /var/lib/kudu/master
> uuid: "e9e534d6c178470f895279a8eca77a5b"
> format_stamp: "Formatted at 2016-09-28 05:41:04 on localhost.localdomain"
> e9e534d6c178470f895279a8eca77a5b
>
> Here are the directory permissions I see in my VMWare VM:
> [training@localhost ~]$ ls -l /var/lib/kudu/master/data/block_manager_instance
> -rw--- 1 kudu kudu 654 Sep 28 01:41
> /var/lib/kudu/master/data/block_manager_instance
> [training@localhost ~]$ ls -l /var/lib/kudu/master/data
> total 4
> -rw--- 1 kudu kudu 654 Sep 28 01:41 block_manager_instance
> [training@localhost ~]$ ls -l /var/lib/kudu/master
> total 20
> drwxr-xr-x 2 kudu kudu 4096 Sep 28 15:11 consensus-meta
> drwxr-xr-x 2 kudu kudu 4096 Sep 28 01:41 data
> -rw--- 1 kudu kudu 665 Sep 28 01:41 instance
> drwxr-xr-x 2 kudu kudu 4096 Sep 28 01:41 tablet-meta
> drwxr-xr-x 3 kudu kudu 4096 Sep 28 15:11 wals
> [training@localhost ~]$ ls -l /var/lib/kudu/master/data
> total 4
> -rw--- 1 kudu kudu 654 Sep 28 01:41 block_manager_instance
> [training@localhost ~]$ ls -l /var/lib/kudu/master/data/block_manager_instance
> -rw--- 1 kudu kudu 654 Sep 28 01:41
> /var/lib/kudu/master/data/block_manager_instance
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KUDU-1665) KUDU lets you create table with wrong/non existent 'kudu.key_columns' columns and then it fails to load/drop the table
[ https://issues.apache.org/jira/browse/KUDU-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavan Kulkarni updated KUDU-1665: - Affects Version/s: (was: 0.10.0) 1.0.0 > KUDU lets you create table with wrong/non existent 'kudu.key_columns' columns > and then it fails to load/drop the table > -- > > Key: KUDU-1665 > URL: https://issues.apache.org/jira/browse/KUDU-1665 > Project: Kudu > Issue Type: Bug > Components: master >Affects Versions: 1.0.0 > Environment: Linux >Reporter: Pavan Kulkarni > Labels: kudu > > Create a table > CREATE TABLE test( > id INT, > display_name STRING > ) > DISTRIBUTE BY RANGE (id) > SPLIT ROWS ((1),(2),(3)) > TBLPROPERTIES( > 'storage_handler' = 'com.cloudera.kudu.hive.KuduStorageHandler', > 'kudu.table_name' = 'test', > 'kudu.master_addresses' = 'master_server:port', > 'kudu.key_columns' = 'id,wrong_column,non_existent_column' > ); > It succesfully creates the table, but on loading or dropping the table you > get an exception as follows: > ERROR: AnalysisException: Some key columns were not found in the set of > columns. List of column names: [wrong_column,non_existent_column] > CAUSED BY: TableLoadingException: Some key columns were not found in the set > of columns. List of column names: [wrong_column,non_existent_column] > The fix should be to check the id columns exist as legit columns in the table > before creating it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KUDU-1665) KUDU lets you create table with wrong/non existent 'kudu.key_columns' columns and then it fails to load/drop the table
[ https://issues.apache.org/jira/browse/KUDU-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533947#comment-15533947 ] Pavan Kulkarni commented on KUDU-1665: -- Sorry for the unrelated comment to the above issue, but I observed that though it's mentioned that SPLIT ROWS is optional with DISTRIBUTE BY RANGE, it throws exception when not provided. Not sure if it's a bug or documentation needs to be updated. Let me know If I have to create a ticket for the same. > KUDU lets you create table with wrong/non existent 'kudu.key_columns' columns > and then it fails to load/drop the table > -- > > Key: KUDU-1665 > URL: https://issues.apache.org/jira/browse/KUDU-1665 > Project: Kudu > Issue Type: Bug > Components: master >Affects Versions: 0.10.0 > Environment: Linux >Reporter: Pavan Kulkarni > Labels: kudu > > Create a table > CREATE TABLE test( > id INT, > display_name STRING > ) > DISTRIBUTE BY RANGE (id) > SPLIT ROWS ((1),(2),(3)) > TBLPROPERTIES( > 'storage_handler' = 'com.cloudera.kudu.hive.KuduStorageHandler', > 'kudu.table_name' = 'test', > 'kudu.master_addresses' = 'master_server:port', > 'kudu.key_columns' = 'id,wrong_column,non_existent_column' > ); > It succesfully creates the table, but on loading or dropping the table you > get an exception as follows: > ERROR: AnalysisException: Some key columns were not found in the set of > columns. List of column names: [wrong_column,non_existent_column] > CAUSED BY: TableLoadingException: Some key columns were not found in the set > of columns. List of column names: [wrong_column,non_existent_column] > The fix should be to check the id columns exist as legit columns in the table > before creating it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KUDU-1665) KUDU lets you create table with wrong/non existent 'kudu.key_columns' columns and then it fails to load/drop the table
Pavan Kulkarni created KUDU-1665: Summary: KUDU lets you create table with wrong/non existent 'kudu.key_columns' columns and then it fails to load/drop the table Key: KUDU-1665 URL: https://issues.apache.org/jira/browse/KUDU-1665 Project: Kudu Issue Type: Bug Components: master Affects Versions: 0.10.0 Environment: Linux Reporter: Pavan Kulkarni Create a table CREATE TABLE test( id INT, display_name STRING ) DISTRIBUTE BY RANGE (id) SPLIT ROWS ((1),(2),(3)) TBLPROPERTIES( 'storage_handler' = 'com.cloudera.kudu.hive.KuduStorageHandler', 'kudu.table_name' = 'test', 'kudu.master_addresses' = 'master_server:port', 'kudu.key_columns' = 'id,wrong_column,non_existent_column' ); It succesfully creates the table, but on loading or dropping the table you get an exception as follows: ERROR: AnalysisException: Some key columns were not found in the set of columns. List of column names: [wrong_column,non_existent_column] CAUSED BY: TableLoadingException: Some key columns were not found in the set of columns. List of column names: [wrong_column,non_existent_column] The fix should be to check the id columns exist as legit columns in the table before creating it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KUDU-1662) Kudu fs command reports permission denied
[
https://issues.apache.org/jira/browse/KUDU-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533901#comment-15533901
]
Dan Burkert commented on KUDU-1662:
---
Sounds like we need to make the instance files world readable. [~adar] or
[~mpercy]: are they locked down for a reason?
> Kudu fs command reports permission denied
> -
>
> Key: KUDU-1662
> URL: https://issues.apache.org/jira/browse/KUDU-1662
> Project: Kudu
> Issue Type: Bug
>Affects Versions: 1.0.0
> Environment: 1. Kudu demo Quickstart VM (VirtualBox) running CDH 5.8
> 2. New Kudu (VMWare) VM running CDH 5.8 in Centos 6.6. with Kudu installed
> from command line (no CM)
>Reporter: Suzanne McIntosh
>Priority: Minor
>
> This is a minor issue because the uuid is ultimately displayed.
> Issuing 'kudu fs dump uuid ...' gives a permission denied error as shown
> below. Testing against the Kudu demo VM yielded the same result. Using sudo
> gives a different error.
> My session below shows results of using plain kudu command, followed by an
> attempt to clear the permission denied message by using sudo:
>
> {code}
> [training@localhost ~]$ kudu fs dump uuid -fs_wal_dir /var/lib/kudu/master
> -fs_data_dirs /var/lib/kudu/master
> I0929 14:57:30.706712 6436 mem_tracker.cc:140] MemTracker: hard memory limit
> is 4.673157 GB
> I0929 14:57:30.706782 6436 mem_tracker.cc:142] MemTracker: soft memory limit
> is 2.803894 GB
> IO error: /var/lib/kudu/master/instance: Permission denied (error 13)
> [training@localhost ~]$ sudo kudu fs dump uuid -fs_wal_dir
> /var/lib/kudu/master -fs_data_dirs /var/lib/kudu/master
> I0929 14:57:44.155582 6448 mem_tracker.cc:140] MemTracker: hard memory limit
> is 4.673157 GB
> I0929 14:57:44.155685 6448 mem_tracker.cc:142] MemTracker: soft memory limit
> is 2.803894 GB
> W0929 14:57:44.157841 6450 log_block_manager.cc:1616] IO error: Could not
> lock /var/lib/kudu/master/data/block_manager_instance: Could not lock
> /var/lib/kudu/master/data/block_manager_instance: lock
> /var/lib/kudu/master/data/block_manager_instance: Resource temporarily
> unavailable (error 11)
> W0929 14:57:44.157857 6450 log_block_manager.cc:1617] Proceeding without lock
> I0929 14:57:44.158095 6448 fs_manager.cc:243] Opened local filesystem:
> /var/lib/kudu/master
> uuid: "e9e534d6c178470f895279a8eca77a5b"
> format_stamp: "Formatted at 2016-09-28 05:41:04 on localhost.localdomain"
> e9e534d6c178470f895279a8eca77a5b
>
> Here are the directory permissions I see in my VMWare VM:
> [training@localhost ~]$ ls -l /var/lib/kudu/master/data/block_manager_instance
> -rw--- 1 kudu kudu 654 Sep 28 01:41
> /var/lib/kudu/master/data/block_manager_instance
> [training@localhost ~]$ ls -l /var/lib/kudu/master/data
> total 4
> -rw--- 1 kudu kudu 654 Sep 28 01:41 block_manager_instance
> [training@localhost ~]$ ls -l /var/lib/kudu/master
> total 20
> drwxr-xr-x 2 kudu kudu 4096 Sep 28 15:11 consensus-meta
> drwxr-xr-x 2 kudu kudu 4096 Sep 28 01:41 data
> -rw--- 1 kudu kudu 665 Sep 28 01:41 instance
> drwxr-xr-x 2 kudu kudu 4096 Sep 28 01:41 tablet-meta
> drwxr-xr-x 3 kudu kudu 4096 Sep 28 15:11 wals
> [training@localhost ~]$ ls -l /var/lib/kudu/master/data
> total 4
> -rw--- 1 kudu kudu 654 Sep 28 01:41 block_manager_instance
> [training@localhost ~]$ ls -l /var/lib/kudu/master/data/block_manager_instance
> -rw--- 1 kudu kudu 654 Sep 28 01:41
> /var/lib/kudu/master/data/block_manager_instance
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KUDU-1662) Kudu fs command reports permission denied
[
https://issues.apache.org/jira/browse/KUDU-1662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Burkert updated KUDU-1662:
--
Description:
This is a minor issue because the uuid is ultimately displayed.
Issuing 'kudu fs dump uuid ...' gives a permission denied error as shown below.
Testing against the Kudu demo VM yielded the same result. Using sudo gives a
different error.
My session below shows results of using plain kudu command, followed by an
attempt to clear the permission denied message by using sudo:
{code}
[training@localhost ~]$ kudu fs dump uuid -fs_wal_dir /var/lib/kudu/master
-fs_data_dirs /var/lib/kudu/master
I0929 14:57:30.706712 6436 mem_tracker.cc:140] MemTracker: hard memory limit
is 4.673157 GB
I0929 14:57:30.706782 6436 mem_tracker.cc:142] MemTracker: soft memory limit
is 2.803894 GB
IO error: /var/lib/kudu/master/instance: Permission denied (error 13)
[training@localhost ~]$ sudo kudu fs dump uuid -fs_wal_dir /var/lib/kudu/master
-fs_data_dirs /var/lib/kudu/master
I0929 14:57:44.155582 6448 mem_tracker.cc:140] MemTracker: hard memory limit
is 4.673157 GB
I0929 14:57:44.155685 6448 mem_tracker.cc:142] MemTracker: soft memory limit
is 2.803894 GB
W0929 14:57:44.157841 6450 log_block_manager.cc:1616] IO error: Could not lock
/var/lib/kudu/master/data/block_manager_instance: Could not lock
/var/lib/kudu/master/data/block_manager_instance: lock
/var/lib/kudu/master/data/block_manager_instance: Resource temporarily
unavailable (error 11)
W0929 14:57:44.157857 6450 log_block_manager.cc:1617] Proceeding without lock
I0929 14:57:44.158095 6448 fs_manager.cc:243] Opened local filesystem:
/var/lib/kudu/master
uuid: "e9e534d6c178470f895279a8eca77a5b"
format_stamp: "Formatted at 2016-09-28 05:41:04 on localhost.localdomain"
e9e534d6c178470f895279a8eca77a5b
Here are the directory permissions I see in my VMWare VM:
[training@localhost ~]$ ls -l /var/lib/kudu/master/data/block_manager_instance
-rw--- 1 kudu kudu 654 Sep 28 01:41
/var/lib/kudu/master/data/block_manager_instance
[training@localhost ~]$ ls -l /var/lib/kudu/master/data
total 4
-rw--- 1 kudu kudu 654 Sep 28 01:41 block_manager_instance
[training@localhost ~]$ ls -l /var/lib/kudu/master
total 20
drwxr-xr-x 2 kudu kudu 4096 Sep 28 15:11 consensus-meta
drwxr-xr-x 2 kudu kudu 4096 Sep 28 01:41 data
-rw--- 1 kudu kudu 665 Sep 28 01:41 instance
drwxr-xr-x 2 kudu kudu 4096 Sep 28 01:41 tablet-meta
drwxr-xr-x 3 kudu kudu 4096 Sep 28 15:11 wals
[training@localhost ~]$ ls -l /var/lib/kudu/master/data
total 4
-rw--- 1 kudu kudu 654 Sep 28 01:41 block_manager_instance
[training@localhost ~]$ ls -l /var/lib/kudu/master/data/block_manager_instance
-rw--- 1 kudu kudu 654 Sep 28 01:41
/var/lib/kudu/master/data/block_manager_instance
{code}
was:
This is a minor issue because the uuid is ultimately displayed.
Issuing 'kudu fs dump uuid ...' gives a permission denied error as shown below.
Testing against the Kudu demo VM yielded the same result. Using sudo gives a
different error.
My session below shows results of using plain kudu command, followed by an
attempt to clear the permission denied message by using sudo:
[training@localhost ~]$ kudu fs dump uuid -fs_wal_dir /var/lib/kudu/master
-fs_data_dirs /var/lib/kudu/master
I0929 14:57:30.706712 6436 mem_tracker.cc:140] MemTracker: hard memory limit
is 4.673157 GB
I0929 14:57:30.706782 6436 mem_tracker.cc:142] MemTracker: soft memory limit
is 2.803894 GB
IO error: /var/lib/kudu/master/instance: Permission denied (error 13)
[training@localhost ~]$ sudo kudu fs dump uuid -fs_wal_dir /var/lib/kudu/master
-fs_data_dirs /var/lib/kudu/master
I0929 14:57:44.155582 6448 mem_tracker.cc:140] MemTracker: hard memory limit
is 4.673157 GB
I0929 14:57:44.155685 6448 mem_tracker.cc:142] MemTracker: soft memory limit
is 2.803894 GB
W0929 14:57:44.157841 6450 log_block_manager.cc:1616] IO error: Could not lock
/var/lib/kudu/master/data/block_manager_instance: Could not lock
/var/lib/kudu/master/data/block_manager_instance: lock
/var/lib/kudu/master/data/block_manager_instance: Resource temporarily
unavailable (error 11)
W0929 14:57:44.157857 6450 log_block_manager.cc:1617] Proceeding without lock
I0929 14:57:44.158095 6448 fs_manager.cc:243] Opened local filesystem:
/var/lib/kudu/master
uuid: "e9e534d6c178470f895279a8eca77a5b"
format_stamp: "Formatted at 2016-09-28 05:41:04 on localhost.localdomain"
e9e534d6c178470f895279a8eca77a5b
Here are the directory permissions I see in my VMWare VM:
[training@localhost ~]$ ls -l /var/lib/kudu/master/data/block_manager_instance
-rw--- 1 kudu kudu 654 Sep 28 01:41
/var/lib/kudu/master/data/block_manager_instance
[training@localhost ~]$ ls -l /var/lib/kudu/master/data
total 4
-rw--- 1 kudu kudu 654 Sep 28 01:41 block_manager_instance
[training@localhost ~]$ ls -l /var/lib/kudu/master
total 20
drwxr-xr-x 2 kudu kudu
[jira] [Created] (KUDU-1664) Clean-up in-code documentation for KuduScanner::ReadMode and KuduClient::GetLatestObservedTimestamp
Alexey Serbin created KUDU-1664:
---
Summary: Clean-up in-code documentation for KuduScanner::ReadMode
and KuduClient::GetLatestObservedTimestamp
Key: KUDU-1664
URL: https://issues.apache.org/jira/browse/KUDU-1664
Project: Kudu
Issue Type: Bug
Components: api, client, documentation
Affects Versions: 1.0.0
Reporter: Alexey Serbin
Priority: Minor
After reading the in-line doc for the subj. entities, one would expect the
scanner from the following code to do its job on reading-what-you-have-written:
{code}
const uint64_t snapshot_timestamp = client->GetLatestObservedTimestamp();
KuduScanner scanner(table.get());
RETURN_NOT_OK(scanner.SetSnapshotRaw(snapshot_timestamp));
RETURN_NOT_OK(scanner.SetReadMode(KuduScanner::READ_AT_SNAPSHOT));
RETURN_NOT_OK(scanner.Open());
{code}
However, it does not work.
To make it work, it's necessary to add extra 1 to the snapshot timestamp:
{code}
RETURN_NOT_OK(scanner.SetSnapshotRaw(snapshot_timestamp + 1));
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KUDU-1661) Mark kudu::client::KuduClient::GetLatestObservedTimestamp() as experimental
Alexey Serbin created KUDU-1661: --- Summary: Mark kudu::client::KuduClient::GetLatestObservedTimestamp() as experimental Key: KUDU-1661 URL: https://issues.apache.org/jira/browse/KUDU-1661 Project: Kudu Issue Type: Improvement Components: client Affects Versions: 1.0.0 Reporter: Alexey Serbin Priority: Minor Per [~dr-alves], the kudu::client::KuduClient::GetLatestObservedTimestamp() method of the Kudu client C++ API is about to change its signature soon to return just an opaque sequence of bytes. So, it should be marked as experimental to inform the users of the current API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KUDU-1660) Kudu master start failed
[ https://issues.apache.org/jira/browse/KUDU-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Burkert resolved KUDU-1660. --- Resolution: Fixed Fix Version/s: 1.0.1 1.1.0 > Kudu master start failed > > > Key: KUDU-1660 > URL: https://issues.apache.org/jira/browse/KUDU-1660 > Project: Kudu > Issue Type: Bug > Components: master >Affects Versions: 1.0.0 >Reporter: Jarred Li > Fix For: 1.1.0, 1.0.1 > > > Kudu is installed with YUM in CentOS 6.5. Kudu master start failed with > following warining: > Log file created at: 2016/09/28 22:57:31 > Running on machine: n1 > Log line format: [IWEF]mmdd hh:mm:ss.uu threadid file:line] msg > W0928 22:57:31.947437 3442 catalog_manager.cc:365] Catalog manager > background task thread going to sleep: Service unavailable: Catalog manager > is not initialized. State: 1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KUDU-1660) Kudu master start failed
[
https://issues.apache.org/jira/browse/KUDU-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533619#comment-15533619
]
Dan Burkert commented on KUDU-1660:
---
This is definitely cause by
https://github.com/apache/kudu/commit/69e65780843040c085ca34901803b97b59595c0e.
For future searchability, here is the smoking gun stack trace:
{code}
W0928 22:57:31.947437 3442 catalog_manager.cc:365] Catalog manager background
task thread going to sleep: Service unavailable: Catalog manager is not
initialized. State: 1
master can not start
kudu-master.out has the following info: *** Aborted at 1475128651 (unix time)
try "date -d @1475128651" if you are using GNU date ***
PC: @ 0x18cd524 (unknown)
*** SIGSEGV (@0xb3b9c380) received by PID 3375 (TID 0x7f508a22e700) from PID
18446744072429880192; stack trace: ***
@ 0x375c60f710 (unknown)
@ 0x18cd524 (unknown)
@ 0xa29251 kudu::codegen::CodeCache::Lookup()
@ 0xa207bc
kudu::codegen::CompilationManager::RequestRowProjector()
@ 0x8bea87 (unknown)
@ 0x8c19be kudu::tablet::MemRowSet::Iterator::Iterator()
@ 0x8c23fa kudu::tablet::MemRowSet::NewIterator()
@ 0x8c2aef kudu::tablet::MemRowSet::NewRowIterator()
@ 0x871ba5 kudu::tablet::Tablet::CaptureConsistentIterators()
@ 0x872662 kudu::tablet::Tablet::Iterator::Init()
@ 0x7ae0ce kudu::master::SysCatalogTable::VisitTables()
@ 0x7c1edb kudu::master::CatalogManager::VisitTablesAndTablets()
@ 0x7c279c
kudu::master::CatalogManager::VisitTablesAndTabletsTask()
@ 0x194c4be kudu::ThreadPool::DispatchThread()
@ 0x194726a kudu::Thread::SuperviseThread()
@ 0x375c6079d1 (unknown)
@ 0x375c2e8b6d (unknown)
@0x0 (unknown)
{code}
> Kudu master start failed
>
>
> Key: KUDU-1660
> URL: https://issues.apache.org/jira/browse/KUDU-1660
> Project: Kudu
> Issue Type: Bug
> Components: master
>Affects Versions: 1.0.0
>Reporter: Jarred Li
>
> Kudu is installed with YUM in CentOS 6.5. Kudu master start failed with
> following warining:
> Log file created at: 2016/09/28 22:57:31
> Running on machine: n1
> Log line format: [IWEF]mmdd hh:mm:ss.uu threadid file:line] msg
> W0928 22:57:31.947437 3442 catalog_manager.cc:365] Catalog manager
> background task thread going to sleep: Service unavailable: Catalog manager
> is not initialized. State: 1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KUDU-1363) Add IN-list predicate type
[
https://issues.apache.org/jira/browse/KUDU-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Burkert updated KUDU-1363:
--
Resolution: Fixed
Fix Version/s: 1.1.0
Status: Resolved (was: In Review)
> Add IN-list predicate type
> --
>
> Key: KUDU-1363
> URL: https://issues.apache.org/jira/browse/KUDU-1363
> Project: Kudu
> Issue Type: Sub-task
> Components: client, perf, tablet
>Reporter: Chris George
>Assignee: Dan Burkert
> Fix For: 1.1.0
>
>
> Currently adding multiple column range predicates for the same column does
> essentially an AND between the two predicates which will cause no results to
> be returned.
> This would greatly increase performance were I can complete in one scan what
> would otherwise take two.
> As an example using the java api:
> ColumnRangePredicate columnRangePredicateColumnNameA = new
> ColumnRangePredicate(new ColumnSchema.ColumnSchemaBuilder("column_name",
> Type.STRING).build());
> columnRangePredicateColumnNameA.setLowerBound("A");
> columnRangePredicateColumnNameA.setUpperBound("A");
> ColumnRangePredicate columnRangePredicateColumnNameB = new
> ColumnRangePredicate(new ColumnSchema.ColumnSchemaBuilder("column_name",
> Type.STRING).build());
> columnRangePredicateColumnNameB.setLowerBound("B");
> columnRangePredicateColumnNameB.setUpperBound("B");
> which would be equivalent:
> select * from some_table where column_name="A" or column_name="B"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (KUDU-1660) Kudu master start failed
[ https://issues.apache.org/jira/browse/KUDU-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533136#comment-15533136 ] Mike Percy commented on KUDU-1660: -- I tried Kudu on CentOS 6.5 and it seems to work; at least it starts up. [~jdcryans] suggested that you may be hitting the bug fixed in https://gerrit.cloudera.org/#/c/4535/ ... do the VMs only have a single CPU? If that is the case then the fix will be included in Kudu 1.0.1, which is a patch release scheduled to go out in a couple of weeks. > Kudu master start failed > > > Key: KUDU-1660 > URL: https://issues.apache.org/jira/browse/KUDU-1660 > Project: Kudu > Issue Type: Bug > Components: master >Affects Versions: 1.0.0 >Reporter: Jarred Li > > Kudu is installed with YUM in CentOS 6.5. Kudu master start failed with > following warining: > Log file created at: 2016/09/28 22:57:31 > Running on machine: n1 > Log line format: [IWEF]mmdd hh:mm:ss.uu threadid file:line] msg > W0928 22:57:31.947437 3442 catalog_manager.cc:365] Catalog manager > background task thread going to sleep: Service unavailable: Catalog manager > is not initialized. State: 1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KUDU-1660) Kudu master start failed
[ https://issues.apache.org/jira/browse/KUDU-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532970#comment-15532970 ] Mike Percy commented on KUDU-1660: -- I think Kudu only supports CentOS 6.6+ but I will get back to you on that > Kudu master start failed > > > Key: KUDU-1660 > URL: https://issues.apache.org/jira/browse/KUDU-1660 > Project: Kudu > Issue Type: Bug > Components: master >Affects Versions: 1.0.0 >Reporter: Jarred Li > > Kudu is installed with YUM in CentOS 6.5. Kudu master start failed with > following warining: > Log file created at: 2016/09/28 22:57:31 > Running on machine: n1 > Log line format: [IWEF]mmdd hh:mm:ss.uu threadid file:line] msg > W0928 22:57:31.947437 3442 catalog_manager.cc:365] Catalog manager > background task thread going to sleep: Service unavailable: Catalog manager > is not initialized. State: 1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KUDU-1458) truncate table support for kudu tables
[ https://issues.apache.org/jira/browse/KUDU-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532534#comment-15532534 ] Mike Percy commented on KUDU-1458: -- I think we should be able to just make some changes to internals at the tablet level to support a truncate operation which would remove all data from the tablet in one shot without modifying partition information. A "delete everything" operation could be implemented as a type of Transaction at the TabletPeer level. > truncate table support for kudu tables > -- > > Key: KUDU-1458 > URL: https://issues.apache.org/jira/browse/KUDU-1458 > Project: Kudu > Issue Type: New Feature > Components: impala, master >Reporter: nick > Labels: newbie > > truncate will come in handy to quickly erase the table. current delete > statement takes long time when the record count is high. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
