[jira] [Reopened] (KUDU-2534) Backup/Restore: Tablet hard limit hit when restoring tables
[
https://issues.apache.org/jira/browse/KUDU-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tony Foerster reopened KUDU-2534:
-
Re-opened. There's a workaround, but any table that's able to be backed up
should also be restorable, even if it breaks a limit, especially since the
limit is allowed to be broken during normal operation. Maybe
`max_create_tablets_per_ts` could be ignored for restores?
> Backup/Restore: Tablet hard limit hit when restoring tables
> ---
>
> Key: KUDU-2534
> URL: https://issues.apache.org/jira/browse/KUDU-2534
> Project: Kudu
> Issue Type: Bug
>Reporter: Tony Foerster
>Priority: Major
>
> It's possible to have tables with greater than the hard limit 300 tablets by
> adding range partitions after creation, but the restore of these tables fails:
>
> {quote}Exception in thread "main"
> org.apache.kudu.client.NonRecoverableException: The requested number of
> tablets is over the maximum permitted at creation time (300). Additional
> tablets may be added by adding range partitions to the table post-creation.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KUDU-2534) Backup/Restore: Tablet hard limit hit when restoring tables
[
https://issues.apache.org/jira/browse/KUDU-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574887#comment-16574887
]
Tony Foerster commented on KUDU-2534:
-
This is a non-issue, tablet creation limit is covered by
`max_create_tablets_per_ts`
> Backup/Restore: Tablet hard limit hit when restoring tables
> ---
>
> Key: KUDU-2534
> URL: https://issues.apache.org/jira/browse/KUDU-2534
> Project: Kudu
> Issue Type: Bug
>Reporter: Tony Foerster
>Priority: Major
>
> It's possible to have tables with greater than the hard limit 300 tablets by
> adding range partitions after creation, but the restore of these tables fails:
>
> {quote}Exception in thread "main"
> org.apache.kudu.client.NonRecoverableException: The requested number of
> tablets is over the maximum permitted at creation time (300). Additional
> tablets may be added by adding range partitions to the table post-creation.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (KUDU-2534) Backup/Restore: Tablet hard limit hit when restoring tables
[
https://issues.apache.org/jira/browse/KUDU-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tony Foerster closed KUDU-2534.
---
Resolution: Not A Problem
> Backup/Restore: Tablet hard limit hit when restoring tables
> ---
>
> Key: KUDU-2534
> URL: https://issues.apache.org/jira/browse/KUDU-2534
> Project: Kudu
> Issue Type: Bug
>Reporter: Tony Foerster
>Priority: Major
>
> It's possible to have tables with greater than the hard limit 300 tablets by
> adding range partitions after creation, but the restore of these tables fails:
>
> {quote}Exception in thread "main"
> org.apache.kudu.client.NonRecoverableException: The requested number of
> tablets is over the maximum permitted at creation time (300). Additional
> tablets may be added by adding range partitions to the table post-creation.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (KUDU-2534) Backup/Restore: Tablet hard limit hit when restoring tables
Tony Foerster created KUDU-2534:
---
Summary: Backup/Restore: Tablet hard limit hit when restoring
tables
Key: KUDU-2534
URL: https://issues.apache.org/jira/browse/KUDU-2534
Project: Kudu
Issue Type: Bug
Reporter: Tony Foerster
It's possible to have tables with greater than the hard limit 300 tablets by
adding range partitions after creation, but the restore of these tables fails:
{quote}Exception in thread "main"
org.apache.kudu.client.NonRecoverableException: The requested number of tablets
is over the maximum permitted at creation time (300). Additional tablets may be
added by adding range partitions to the table post-creation.
{quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KUDU-2524) scalafmt incompatible with jdk8 older than u25
[
https://issues.apache.org/jira/browse/KUDU-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565806#comment-16565806
]
Tony Foerster commented on KUDU-2524:
-
Looks like I can skip the scalafmt in Maven using profiles. I still need to
figure out how to do this in Gradle.
Unless someone think blacklist is the better option I'll submit a patch.
> scalafmt incompatible with jdk8 older than u25
> --
>
> Key: KUDU-2524
> URL: https://issues.apache.org/jira/browse/KUDU-2524
> Project: Kudu
> Issue Type: Bug
> Components: java
>Affects Versions: 1.8.0
>Reporter: Adar Dembo
>Priority: Major
>
> We're seeing a fair number of Gradle build failures in scalafmt with the
> following output:
> {noformat}
> 1: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':kudu-spark:scalafmt'.
> > Uninitialized object exists on backward branch 209
> Exception Details:
> Location:
>
> scala/collection/immutable/HashMap$HashTrieMap.split()Lscala/collection/immutable/Seq;
> @249: goto
> Reason:
> Error exists in the bytecode
> Bytecode:
> 000: 2ab6 005b 04a0 001e b200 b3b2 00b8 04bd
> 010: 0002 5903 2a53 c000 bab6 00be b600 c2c0
> 020: 00c4 b02a b600 31b8 003b 3c1b 04a4 015e
> 030: 1b05 6c3d 2a1b 056c 2ab6 0031 b700 c63e
> 040: 2ab6 0031 021d 787e 3604 2ab6 0031 0210
> 050: 201d 647c 7e36 05bb 0014 59b2 00b8 2ab6
> 060: 0033 c000 bab6 00ca b700 cd1c b600 d13a
> 070: 0619 06c6 001a 1906 b600 d5c0 0081 3a07
> 080: 1906 b600 d8c0 0081 3a08 a700 0dbb 00da
> 090: 5919 06b7 00dd bf19 073a 0919 083a 0abb
> 0a0: 0002 5915 0419 09bb 0014 59b2 00b8 1909
> 0b0: c000 bab6 00ca b700 cd03 b800 e33a 0e3a
> 0c0: 0d03 190d b900 e701 0019 0e3a 1136 1036
> 0d0: 0f15 0f15 109f 0027 150f 0460 1510 190d
> 0e0: 150f b900 ea02 00c0 0005 3a17 1911 1917
> 0f0: b800 ee3a 1136 1036 0fa7 ffd8 1911 b800
> 100: f2b7 0060 3a0b bb00 0259 1505 190a bb00
> 110: 1459 b200 b819 0ac0 00ba b600 cab7 00cd
> 120: 03b8 00e3 3a13 3a12 0319 12b9 00e7 0100
> 130: 1913 3a16 3615 3614 1514 1515 9f00 2715
> 140: 1404 6015 1519 1215 14b9 00ea 0200 c000
> 150: 053a 1819 1619 18b8 00f5 3a16 3615 3614
> 160: a7ff d819 16b8 00f2 b700 603a 0cb2 00fa
> 170: b200 b805 bd00 0259 0319 0b53 5904 190c
> 180: 53c0 00ba b600 beb6 00fd b02a b600 3303
> 190: 32b6 00ff b0
> Stackmap Table:
> same_frame(@35)
>
> full_frame(@141,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#109]},{})
> append_frame(@151,Object[#129],Object[#129])
>
> full_frame(@209,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#109],Object[#129],Object[#129],Object[#129],Object[#129],Top,Top,Object[#20],Object[#55],Integer,Integer,Object[#107]},{Uninitialized[#159],Uninitialized[#159],Integer,Object[#129]})
>
> full_frame(@252,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#109],Object[#129],Object[#129],Object[#129],Object[#129],Top,Top,Object[#20],Object[#55],Integer,Integer,Object[#107]},{Uninitialized[#159],Uninitialized[#159],Integer,Object[#129]})
>
> full_frame(@312,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#109],Object[#129],Object[#129],Object[#129],Object[#129],Object[#2],Top,Object[#20],Object[#55],Integer,Integer,Object[#107],Object[#20],Object[#55],Integer,Integer,Object[#107]},{Uninitialized[#262],Uninitialized[#262],Integer,Object[#129]})
>
> full_frame(@355,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#109],Object[#129],Object[#129],Object[#129],Object[#129],Object[#2],Top,Object[#20],Object[#55],Integer,Integer,Object[#107],Object[#20],Object[#55],Integer,Integer,Object[#107]},{Uninitialized[#262],Uninitialized[#262],Integer,Object[#129]})
> full_frame(@395,{Object[#2],Integer},{}){noformat}
> This appears to be due to [this JDK
> issue|https://stackoverflow.com/questions/24061672/verifyerror-uninitialized-object-exists-on-backward-branch-jvm-spec-4-10-2-4],
> which was fixed in JDK 8u25.
> And sure enough, here's the JDK version for failing builds:
> {noformat}
> -- Found Java: /opt/toolchain/sun-jdk-64bit-1.8.0.05/bin/java (found suitable
> version "1.8.0.05", minimum required is "1.7")
> {noformat}
> And here it is for successful builds:
> {noformat}
> 19:06:12 -- Found Java: /usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/java (found
> suitable version "1.8.0.111", minimum required is "1.7")
> {noformat}
> We either need to blacklist JDK8 versions older than u25, or we need to
> condition the scalafmt step on the
[jira] [Commented] (KUDU-2524) scalafmt incompatible with jdk8 older than u25
[
https://issues.apache.org/jira/browse/KUDU-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16565793#comment-16565793
]
Tony Foerster commented on KUDU-2524:
-
[~adar] version 8.u25 [expired January
2015|https://www.oracle.com/technetwork/java/javase/8u25-relnotes-2296185.html],
so it's pretty old. Personally I think that could be blacklisted.
I'm guessing skipping the scalafmt step for older version in Gradle would be
doable since it's a little more flexible, but I don't know of anything in the
Maven build that would allow us to do that.
> scalafmt incompatible with jdk8 older than u25
> --
>
> Key: KUDU-2524
> URL: https://issues.apache.org/jira/browse/KUDU-2524
> Project: Kudu
> Issue Type: Bug
> Components: java
>Affects Versions: 1.8.0
>Reporter: Adar Dembo
>Priority: Major
>
> We're seeing a fair number of Gradle build failures in scalafmt with the
> following output:
> {noformat}
> 1: Task failed with an exception.
> ---
> * What went wrong:
> Execution failed for task ':kudu-spark:scalafmt'.
> > Uninitialized object exists on backward branch 209
> Exception Details:
> Location:
>
> scala/collection/immutable/HashMap$HashTrieMap.split()Lscala/collection/immutable/Seq;
> @249: goto
> Reason:
> Error exists in the bytecode
> Bytecode:
> 000: 2ab6 005b 04a0 001e b200 b3b2 00b8 04bd
> 010: 0002 5903 2a53 c000 bab6 00be b600 c2c0
> 020: 00c4 b02a b600 31b8 003b 3c1b 04a4 015e
> 030: 1b05 6c3d 2a1b 056c 2ab6 0031 b700 c63e
> 040: 2ab6 0031 021d 787e 3604 2ab6 0031 0210
> 050: 201d 647c 7e36 05bb 0014 59b2 00b8 2ab6
> 060: 0033 c000 bab6 00ca b700 cd1c b600 d13a
> 070: 0619 06c6 001a 1906 b600 d5c0 0081 3a07
> 080: 1906 b600 d8c0 0081 3a08 a700 0dbb 00da
> 090: 5919 06b7 00dd bf19 073a 0919 083a 0abb
> 0a0: 0002 5915 0419 09bb 0014 59b2 00b8 1909
> 0b0: c000 bab6 00ca b700 cd03 b800 e33a 0e3a
> 0c0: 0d03 190d b900 e701 0019 0e3a 1136 1036
> 0d0: 0f15 0f15 109f 0027 150f 0460 1510 190d
> 0e0: 150f b900 ea02 00c0 0005 3a17 1911 1917
> 0f0: b800 ee3a 1136 1036 0fa7 ffd8 1911 b800
> 100: f2b7 0060 3a0b bb00 0259 1505 190a bb00
> 110: 1459 b200 b819 0ac0 00ba b600 cab7 00cd
> 120: 03b8 00e3 3a13 3a12 0319 12b9 00e7 0100
> 130: 1913 3a16 3615 3614 1514 1515 9f00 2715
> 140: 1404 6015 1519 1215 14b9 00ea 0200 c000
> 150: 053a 1819 1619 18b8 00f5 3a16 3615 3614
> 160: a7ff d819 16b8 00f2 b700 603a 0cb2 00fa
> 170: b200 b805 bd00 0259 0319 0b53 5904 190c
> 180: 53c0 00ba b600 beb6 00fd b02a b600 3303
> 190: 32b6 00ff b0
> Stackmap Table:
> same_frame(@35)
>
> full_frame(@141,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#109]},{})
> append_frame(@151,Object[#129],Object[#129])
>
> full_frame(@209,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#109],Object[#129],Object[#129],Object[#129],Object[#129],Top,Top,Object[#20],Object[#55],Integer,Integer,Object[#107]},{Uninitialized[#159],Uninitialized[#159],Integer,Object[#129]})
>
> full_frame(@252,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#109],Object[#129],Object[#129],Object[#129],Object[#129],Top,Top,Object[#20],Object[#55],Integer,Integer,Object[#107]},{Uninitialized[#159],Uninitialized[#159],Integer,Object[#129]})
>
> full_frame(@312,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#109],Object[#129],Object[#129],Object[#129],Object[#129],Object[#2],Top,Object[#20],Object[#55],Integer,Integer,Object[#107],Object[#20],Object[#55],Integer,Integer,Object[#107]},{Uninitialized[#262],Uninitialized[#262],Integer,Object[#129]})
>
> full_frame(@355,{Object[#2],Integer,Integer,Integer,Integer,Integer,Object[#109],Object[#129],Object[#129],Object[#129],Object[#129],Object[#2],Top,Object[#20],Object[#55],Integer,Integer,Object[#107],Object[#20],Object[#55],Integer,Integer,Object[#107]},{Uninitialized[#262],Uninitialized[#262],Integer,Object[#129]})
> full_frame(@395,{Object[#2],Integer},{}){noformat}
> This appears to be due to [this JDK
> issue|https://stackoverflow.com/questions/24061672/verifyerror-uninitialized-object-exists-on-backward-branch-jvm-spec-4-10-2-4],
> which was fixed in JDK 8u25.
> And sure enough, here's the JDK version for failing builds:
> {noformat}
> -- Found Java: /opt/toolchain/sun-jdk-64bit-1.8.0.05/bin/java (found suitable
> version "1.8.0.05", minimum required is "1.7")
> {noformat}
> And here it is for successful builds:
> {noformat}
> 19:06:12 -- Found Java:
[jira] [Updated] (KUDU-428) Support for service/table/column authorization
[ https://issues.apache.org/jira/browse/KUDU-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Foerster updated KUDU-428: --- Target Version/s: (was: Backlog) > Support for service/table/column authorization > -- > > Key: KUDU-428 > URL: https://issues.apache.org/jira/browse/KUDU-428 > Project: Kudu > Issue Type: New Feature > Components: master, security, tserver >Affects Versions: 1.2.0 >Reporter: Todd Lipcon >Priority: Critical > Labels: kudu-roadmap > > We need to support basic SQL-like access control: > - grant/revoke on tables, columns > - service-level grant/revoke > - probably need some group/role mapping infrastructure as well -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (KUDU-2095) scanner keepAlive method is necessary in java client
[ https://issues.apache.org/jira/browse/KUDU-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tony Foerster reassigned KUDU-2095: --- Assignee: Tony Foerster > scanner keepAlive method is necessary in java client > > > Key: KUDU-2095 > URL: https://issues.apache.org/jira/browse/KUDU-2095 > Project: Kudu > Issue Type: Bug >Affects Versions: 1.3.1 >Reporter: zhangguangqiang >Assignee: Tony Foerster > > when I use kudu java client，I need to make scanner to keepAlive in my usage > case。But I can not find this method in java client; On the other hand，I found > kudu::client::KuduScanner::KeepAlive in c++ client。This is very necessary in > my usage，will you implement it in java client？ thank you ！ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
