[jira] [Created] (HBASE-9849) [REST] Forbidden schema delete in read only mode
Julian Zhou created HBASE-9849: -- Summary: [REST] Forbidden schema delete in read only mode Key: HBASE-9849 URL: https://issues.apache.org/jira/browse/HBASE-9849 Project: HBase Issue Type: Bug Components: REST Affects Versions: 0.98.0, 0.94.14 Reporter: Julian Zhou Assignee: Julian Zhou Fix For: 0.98.0, 0.94.14 If hbase.rest.readonly was set, all write operations should be forbidden via REST, right? So table schema deletion should also be forbidden in readonly mode? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (HBASE-9849) [REST] Forbidden schema delete in read only mode
[ https://issues.apache.org/jira/browse/HBASE-9849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-9849: --- Attachment: 9849-trunk-v0.patch 9849-0.94-v0.patch [REST] Forbidden schema delete in read only mode Key: HBASE-9849 URL: https://issues.apache.org/jira/browse/HBASE-9849 Project: HBase Issue Type: Bug Components: REST Affects Versions: 0.98.0, 0.94.14 Reporter: Julian Zhou Assignee: Julian Zhou Fix For: 0.98.0, 0.94.14 Attachments: 9849-0.94-v0.patch, 9849-trunk-v0.patch If hbase.rest.readonly was set, all write operations should be forbidden via REST, right? So table schema deletion should also be forbidden in readonly mode? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (HBASE-9849) [REST] Forbidden schema delete in read only mode
[ https://issues.apache.org/jira/browse/HBASE-9849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-9849: --- Status: Patch Available (was: Open) [REST] Forbidden schema delete in read only mode Key: HBASE-9849 URL: https://issues.apache.org/jira/browse/HBASE-9849 Project: HBase Issue Type: Bug Components: REST Affects Versions: 0.98.0, 0.94.14 Reporter: Julian Zhou Assignee: Julian Zhou Fix For: 0.98.0, 0.94.14 Attachments: 9849-0.94-v0.patch, 9849-trunk-v0.patch If hbase.rest.readonly was set, all write operations should be forbidden via REST, right? So table schema deletion should also be forbidden in readonly mode? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (HBASE-9747) PrefixFilter with OR condition gives wrong results
[
https://issues.apache.org/jira/browse/HBASE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13797660#comment-13797660
]
Julian Zhou commented on HBASE-9747:
Hi Stack, are the patches ok for the commits? Then we may could integrate in
our solution/products' releasing as JIRA backport. Thanks~
PrefixFilter with OR condition gives wrong results
--
Key: HBASE-9747
URL: https://issues.apache.org/jira/browse/HBASE-9747
Project: HBase
Issue Type: Bug
Components: Filters
Affects Versions: 0.95.2, 0.94.9
Reporter: Deepa Remesh
Assignee: Aditya Kishore
Attachments: HBASE-9747_0.94.patch, HBASE-9747.patch
PrefixFilter when used with a SingleColumnValueFilter with an OR condition
gives wrong results. In below example, each filter when evaluated separately
gives 1 row each. The OR condition with the two filters gives 3 rows instead
of 2. Repro below:
create 't1', 'f1'
put 't1','a1','f1:q2','111'
put 't1','b1','f1:q1','112'
put 't1','c1','f1:q1','113'
hbase(main):020:0 scan 't1', {FILTER = PrefixFilter ('b') OR
SingleColumnValueFilter('f1', 'q1', =, 'binary:113')}
ROWCOLUMN+CELL
a1column=f1:q2,
timestamp=1381468905492, value=111
b1column=f1:q1,
timestamp=1381468905518, value=112
c1column=f1:q1,
timestamp=1381468905549, value=113
3 row(s) in 0.1020 seconds
hbase(main):021:0 scan 't1', {FILTER = PrefixFilter ('b')}
ROWCOLUMN+CELL
b1column=f1:q1,
timestamp=1381468905518, value=112
1 row(s) in 0.0150 seconds
hbase(main):002:0 scan 't1', {FILTER = SingleColumnValueFilter('f1', 'q1',
=, 'binary:113')}
ROWCOLUMN+CELL
c1column=f1:q1,
timestamp=1381469178679, value=113
1 row(s) in 0.0140 seconds
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (HBASE-9747) PrefixFilter with OR condition gives wrong results
[
https://issues.apache.org/jira/browse/HBASE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13793904#comment-13793904
]
Julian Zhou commented on HBASE-9747:
Patches works for the case for me.
PrefixFilter with OR condition gives wrong results
--
Key: HBASE-9747
URL: https://issues.apache.org/jira/browse/HBASE-9747
Project: HBase
Issue Type: Bug
Components: Filters
Affects Versions: 0.95.2, 0.94.9
Reporter: Deepa Remesh
Assignee: Aditya Kishore
Attachments: HBASE-9747_0.94.patch, HBASE-9747.patch
PrefixFilter when used with a SingleColumnValueFilter with an OR condition
gives wrong results. In below example, each filter when evaluated separately
gives 1 row each. The OR condition with the two filters gives 3 rows instead
of 2. Repro below:
create 't1', 'f1'
put 't1','a1','f1:q2','111'
put 't1','b1','f1:q1','112'
put 't1','c1','f1:q1','113'
hbase(main):020:0 scan 't1', {FILTER = PrefixFilter ('b') OR
SingleColumnValueFilter('f1', 'q1', =, 'binary:113')}
ROWCOLUMN+CELL
a1column=f1:q2,
timestamp=1381468905492, value=111
b1column=f1:q1,
timestamp=1381468905518, value=112
c1column=f1:q1,
timestamp=1381468905549, value=113
3 row(s) in 0.1020 seconds
hbase(main):021:0 scan 't1', {FILTER = PrefixFilter ('b')}
ROWCOLUMN+CELL
b1column=f1:q1,
timestamp=1381468905518, value=112
1 row(s) in 0.0150 seconds
hbase(main):002:0 scan 't1', {FILTER = SingleColumnValueFilter('f1', 'q1',
=, 'binary:113')}
ROWCOLUMN+CELL
c1column=f1:q1,
timestamp=1381469178679, value=113
1 row(s) in 0.0140 seconds
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (HBASE-9747) PrefixFilter with OR condition gives wrong results
[
https://issues.apache.org/jira/browse/HBASE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792403#comment-13792403
]
Julian Zhou commented on HBASE-9747:
Is this kinds of logic? --
In the for loop of FilterList#filterRowKey, there are 2 filters in this case:
PrefixFilter and SingleColumnValueFilter. The 1st row 'a1','f1:q2','111' was
filtered by PrefixFilter, but was passed (survived) via the 2nd filter
SingleColumnValueFilter, since SingleColumnValueFilter is actually not a rowkey
filter but a row/kv filter, but it inherits from
FilterBase#filterAllRemaining() and FilterBase#filterRowKey's returning false
value, which is not expected in this case.
Sounds like we need to deny the non-rowkey filter in the rowkey filter
execution path to avoid the filtered row survived?
PrefixFilter with OR condition gives wrong results
--
Key: HBASE-9747
URL: https://issues.apache.org/jira/browse/HBASE-9747
Project: HBase
Issue Type: Bug
Components: Filters
Affects Versions: 0.94.9
Reporter: Deepa Remesh
PrefixFilter when used with a SingleColumnValueFilter with an OR condition
gives wrong results. In below example, each filter when evaluated separately
gives 1 row each. The OR condition with the two filters gives 3 rows instead
of 2. Repro below:
create 't1', 'f1'
put 't1','a1','f1:q2','111'
put 't1','b1','f1:q1','112'
put 't1','c1','f1:q1','113'
hbase(main):020:0 scan 't1', {FILTER = PrefixFilter ('b') OR
SingleColumnValueFilter('f1', 'q1', =, 'binary:113')}
ROWCOLUMN+CELL
a1column=f1:q2,
timestamp=1381468905492, value=111
b1column=f1:q1,
timestamp=1381468905518, value=112
c1column=f1:q1,
timestamp=1381468905549, value=113
3 row(s) in 0.1020 seconds
hbase(main):021:0 scan 't1', {FILTER = PrefixFilter ('b')}
ROWCOLUMN+CELL
b1column=f1:q1,
timestamp=1381468905518, value=112
1 row(s) in 0.0150 seconds
hbase(main):002:0 scan 't1', {FILTER = SingleColumnValueFilter('f1', 'q1',
=, 'binary:113')}
ROWCOLUMN+CELL
c1column=f1:q1,
timestamp=1381469178679, value=113
1 row(s) in 0.0140 seconds
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (HBASE-9139) Independent timeout configuration for rpc channel between cluster nodes
[ https://issues.apache.org/jira/browse/HBASE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-9139: --- Attachment: 9139-trunk-v0.patch Independent timeout configuration for rpc channel between cluster nodes --- Key: HBASE-9139 URL: https://issues.apache.org/jira/browse/HBASE-9139 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 0.94.10, 0.96.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.12, 0.96.0 Attachments: 9139-0.94-v0.patch, 9139-trunk-v0.patch Default of hbase.rpc.timeout is 6 ms (1 min). User sometimes increase them to a bigger value such as 60 ms (10 mins) for many concurrent loading application from client. Some user share the same hbase-site.xml for both client and server. HRegionServer #tryRegionServerReport via rpc channel to report to live master, but there was a window for master failover scenario. That region server attempting to connect to master, which was just killed, backup master took the active role immediately and put to /hbase/master, but region server was still waiting for the rpc timeout from connecting to the dead master. If hbase.rpc.timeout is too long, this master failover process will be long due to long rpc timeout from dead master. If so, could we separate with 2 options, hbase.rpc.timeout is still for hbase client, while hbase.rpc.internal.timeout was for this regionserver/master rpc channel, which could be set shorted value without affect real client rpc timeout value? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9139) Independent timeout configuration for rpc channel between cluster nodes
[ https://issues.apache.org/jira/browse/HBASE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734538#comment-13734538 ] Julian Zhou commented on HBASE-9139: Hi [~nkeywal], attached the trunk patch v0. I searched out all reference places of HBASE_RPC_TIMEOUT_KEY and hbase.rpc.timeout. Besides test/ code, only we have HCM and regionserver code to initialize the rpc timeout value. HCM still base on hbase.rpc.timeout, so seems we only need to apply the new conf for regionserver's rpc timeout. So seems the change is straightforward and simple. Could you help review? Thanks [~nkeywal] and [~lhofhansl]. Independent timeout configuration for rpc channel between cluster nodes --- Key: HBASE-9139 URL: https://issues.apache.org/jira/browse/HBASE-9139 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 0.94.10, 0.96.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.12, 0.96.0 Attachments: 9139-0.94-v0.patch, 9139-trunk-v0.patch Default of hbase.rpc.timeout is 6 ms (1 min). User sometimes increase them to a bigger value such as 60 ms (10 mins) for many concurrent loading application from client. Some user share the same hbase-site.xml for both client and server. HRegionServer #tryRegionServerReport via rpc channel to report to live master, but there was a window for master failover scenario. That region server attempting to connect to master, which was just killed, backup master took the active role immediately and put to /hbase/master, but region server was still waiting for the rpc timeout from connecting to the dead master. If hbase.rpc.timeout is too long, this master failover process will be long due to long rpc timeout from dead master. If so, could we separate with 2 options, hbase.rpc.timeout is still for hbase client, while hbase.rpc.internal.timeout was for this regionserver/master rpc channel, which could be set shorted value without affect real client rpc timeout value? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9139) Independent timeout configuration for rpc channel between cluster nodes
[ https://issues.apache.org/jira/browse/HBASE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-9139: --- Attachment: 9139-trunk-v1.patch Independent timeout configuration for rpc channel between cluster nodes --- Key: HBASE-9139 URL: https://issues.apache.org/jira/browse/HBASE-9139 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 0.94.10, 0.96.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.12, 0.96.0 Attachments: 9139-0.94-v0.patch, 9139-trunk-v0.patch, 9139-trunk-v1.patch Default of hbase.rpc.timeout is 6 ms (1 min). User sometimes increase them to a bigger value such as 60 ms (10 mins) for many concurrent loading application from client. Some user share the same hbase-site.xml for both client and server. HRegionServer #tryRegionServerReport via rpc channel to report to live master, but there was a window for master failover scenario. That region server attempting to connect to master, which was just killed, backup master took the active role immediately and put to /hbase/master, but region server was still waiting for the rpc timeout from connecting to the dead master. If hbase.rpc.timeout is too long, this master failover process will be long due to long rpc timeout from dead master. If so, could we separate with 2 options, hbase.rpc.timeout is still for hbase client, while hbase.rpc.internal.timeout was for this regionserver/master rpc channel, which could be set shorted value without affect real client rpc timeout value? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9139) Independent timeout configuration for rpc channel between cluster nodes
[ https://issues.apache.org/jira/browse/HBASE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-9139: --- Attachment: 9139-0.94-v1.patch Independent timeout configuration for rpc channel between cluster nodes --- Key: HBASE-9139 URL: https://issues.apache.org/jira/browse/HBASE-9139 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 0.94.10, 0.96.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.12, 0.96.0 Attachments: 9139-0.94-v0.patch, 9139-0.94-v1.patch, 9139-trunk-v0.patch, 9139-trunk-v1.patch Default of hbase.rpc.timeout is 6 ms (1 min). User sometimes increase them to a bigger value such as 60 ms (10 mins) for many concurrent loading application from client. Some user share the same hbase-site.xml for both client and server. HRegionServer #tryRegionServerReport via rpc channel to report to live master, but there was a window for master failover scenario. That region server attempting to connect to master, which was just killed, backup master took the active role immediately and put to /hbase/master, but region server was still waiting for the rpc timeout from connecting to the dead master. If hbase.rpc.timeout is too long, this master failover process will be long due to long rpc timeout from dead master. If so, could we separate with 2 options, hbase.rpc.timeout is still for hbase client, while hbase.rpc.internal.timeout was for this regionserver/master rpc channel, which could be set shorted value without affect real client rpc timeout value? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9139) Independent timeout configuration for rpc channel between cluster nodes
[ https://issues.apache.org/jira/browse/HBASE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13734945#comment-13734945 ] Julian Zhou commented on HBASE-9139: Hi [~nkeywal], attached the v1 for trunk and 0.94 patch with description in hbase-default.xml. Thanks for reviewing the wording, I will apply the comments if any. For hbase-default.xml in 0.94, we do not have description for hbase.rpc.timeout, so I copy both hbase.rpc.timeout and hbase.rpc.shortoperation.timeout from trunk. [~lhofhansl], is it ok to have them? Independent timeout configuration for rpc channel between cluster nodes --- Key: HBASE-9139 URL: https://issues.apache.org/jira/browse/HBASE-9139 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 0.94.10, 0.96.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.12, 0.96.0 Attachments: 9139-0.94-v0.patch, 9139-0.94-v1.patch, 9139-trunk-v0.patch, 9139-trunk-v1.patch Default of hbase.rpc.timeout is 6 ms (1 min). User sometimes increase them to a bigger value such as 60 ms (10 mins) for many concurrent loading application from client. Some user share the same hbase-site.xml for both client and server. HRegionServer #tryRegionServerReport via rpc channel to report to live master, but there was a window for master failover scenario. That region server attempting to connect to master, which was just killed, backup master took the active role immediately and put to /hbase/master, but region server was still waiting for the rpc timeout from connecting to the dead master. If hbase.rpc.timeout is too long, this master failover process will be long due to long rpc timeout from dead master. If so, could we separate with 2 options, hbase.rpc.timeout is still for hbase client, while hbase.rpc.internal.timeout was for this regionserver/master rpc channel, which could be set shorted value without affect real client rpc timeout value? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9139) Independent timeout configuration for rpc channel between cluster nodes
[ https://issues.apache.org/jira/browse/HBASE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-9139: --- Assignee: Julian Zhou Independent timeout configuration for rpc channel between cluster nodes --- Key: HBASE-9139 URL: https://issues.apache.org/jira/browse/HBASE-9139 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 0.94.10, 0.96.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.12, 0.96.0 Default of hbase.rpc.timeout is 6 ms (1 min). User sometimes increase them to a bigger value such as 60 ms (10 mins) for many concurrent loading application from client. Some user share the same hbase-site.xml for both client and server. HRegionServer #tryRegionServerReport via rpc channel to report to live master, but there was a window for master failover scenario. That region server attempting to connect to master, which was just killed, backup master took the active role immediately and put to /hbase/master, but region server was still waiting for the rpc timeout from connecting to the dead master. If hbase.rpc.timeout is too long, this master failover process will be long due to long rpc timeout from dead master. If so, could we separate with 2 options, hbase.rpc.timeout is still for hbase client, while hbase.rpc.internal.timeout was for this regionserver/master rpc channel, which could be set shorted value without affect real client rpc timeout value? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9139) Independent timeout configuration for rpc channel between cluster nodes
[ https://issues.apache.org/jira/browse/HBASE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-9139: --- Attachment: 9139-0.94-v0.patch Independent timeout configuration for rpc channel between cluster nodes --- Key: HBASE-9139 URL: https://issues.apache.org/jira/browse/HBASE-9139 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 0.94.10, 0.96.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.12, 0.96.0 Attachments: 9139-0.94-v0.patch Default of hbase.rpc.timeout is 6 ms (1 min). User sometimes increase them to a bigger value such as 60 ms (10 mins) for many concurrent loading application from client. Some user share the same hbase-site.xml for both client and server. HRegionServer #tryRegionServerReport via rpc channel to report to live master, but there was a window for master failover scenario. That region server attempting to connect to master, which was just killed, backup master took the active role immediately and put to /hbase/master, but region server was still waiting for the rpc timeout from connecting to the dead master. If hbase.rpc.timeout is too long, this master failover process will be long due to long rpc timeout from dead master. If so, could we separate with 2 options, hbase.rpc.timeout is still for hbase client, while hbase.rpc.internal.timeout was for this regionserver/master rpc channel, which could be set shorted value without affect real client rpc timeout value? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9139) Independent timeout configuration for rpc channel between cluster nodes
[ https://issues.apache.org/jira/browse/HBASE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733241#comment-13733241 ] Julian Zhou commented on HBASE-9139: Hi [~nkeywal], agree. I just attached the v0 patch for 0.94, currently, seems that only regionserver's reporting to master needs this short rpc timeout setting. HConnectionManager for client call is w/o this change. Could you help review? If the trunk logic for this was the same, I will attach the version for trunk afterwards. Thanks~ Independent timeout configuration for rpc channel between cluster nodes --- Key: HBASE-9139 URL: https://issues.apache.org/jira/browse/HBASE-9139 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 0.94.10, 0.96.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.12, 0.96.0 Attachments: 9139-0.94-v0.patch Default of hbase.rpc.timeout is 6 ms (1 min). User sometimes increase them to a bigger value such as 60 ms (10 mins) for many concurrent loading application from client. Some user share the same hbase-site.xml for both client and server. HRegionServer #tryRegionServerReport via rpc channel to report to live master, but there was a window for master failover scenario. That region server attempting to connect to master, which was just killed, backup master took the active role immediately and put to /hbase/master, but region server was still waiting for the rpc timeout from connecting to the dead master. If hbase.rpc.timeout is too long, this master failover process will be long due to long rpc timeout from dead master. If so, could we separate with 2 options, hbase.rpc.timeout is still for hbase client, while hbase.rpc.internal.timeout was for this regionserver/master rpc channel, which could be set shorted value without affect real client rpc timeout value? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9139) Independent timeout configuration for rpc channel between cluster nodes
[ https://issues.apache.org/jira/browse/HBASE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13733242#comment-13733242 ] Julian Zhou commented on HBASE-9139: Currently, I just name it as hbase.rpc.shortoperation.timeout, default is 10s. Independent timeout configuration for rpc channel between cluster nodes --- Key: HBASE-9139 URL: https://issues.apache.org/jira/browse/HBASE-9139 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 0.94.10, 0.96.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.12, 0.96.0 Attachments: 9139-0.94-v0.patch Default of hbase.rpc.timeout is 6 ms (1 min). User sometimes increase them to a bigger value such as 60 ms (10 mins) for many concurrent loading application from client. Some user share the same hbase-site.xml for both client and server. HRegionServer #tryRegionServerReport via rpc channel to report to live master, but there was a window for master failover scenario. That region server attempting to connect to master, which was just killed, backup master took the active role immediately and put to /hbase/master, but region server was still waiting for the rpc timeout from connecting to the dead master. If hbase.rpc.timeout is too long, this master failover process will be long due to long rpc timeout from dead master. If so, could we separate with 2 options, hbase.rpc.timeout is still for hbase client, while hbase.rpc.internal.timeout was for this regionserver/master rpc channel, which could be set shorted value without affect real client rpc timeout value? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8533: --- Component/s: (was: scripts) (was: REST) [REST] HBaseAdmin does not ride over cluster restart Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Affects Versions: 0.98.0, 0.95.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0 Attachments: 8533-0.95-v1.patch, 8533-trunk-v1.patch, hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8533) HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8533: --- Summary: HBaseAdmin does not ride over cluster restart (was: [REST] HBaseAdmin does not ride over cluster restart) HBaseAdmin does not ride over cluster restart - Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Affects Versions: 0.98.0, 0.95.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0 Attachments: 8533-0.95-v1.patch, 8533-trunk-v1.patch, hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8533) HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8533: --- Component/s: Client HBaseAdmin does not ride over cluster restart - Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: Client Affects Versions: 0.98.0, 0.95.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0 Attachments: 8533-0.95-v1.patch, 8533-trunk-v1.patch, hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-9139) Independent timeout configuration for rpc channel between cluster nodes
Julian Zhou created HBASE-9139: -- Summary: Independent timeout configuration for rpc channel between cluster nodes Key: HBASE-9139 URL: https://issues.apache.org/jira/browse/HBASE-9139 Project: HBase Issue Type: Improvement Components: IPC/RPC, regionserver Affects Versions: 0.94.10, 0.96.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.94.11, 0.96.0 Default of hbase.rpc.timeout is 6 ms (1 min). User sometimes increase them to a bigger value such as 60 ms (10 mins) for many concurrent loading application from client. Some user share the same hbase-site.xml for both client and server. HRegionServer #tryRegionServerReport via rpc channel to report to live master, but there was a window for master failover scenario. That region server attempting to connect to master, which was just killed, backup master took the active role immediately and put to /hbase/master, but region server was still waiting for the rpc timeout from connecting to the dead master. If hbase.rpc.timeout is too long, this master failover process will be long due to long rpc timeout from dead master. If so, could we separate with 2 options, hbase.rpc.timeout is still for hbase client, while hbase.rpc.internal.timeout was for this regionserver/master rpc channel, which could be set shorted value without affect real client rpc timeout value? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8685) [REST] Minor fix to XMLSchema.xsd and ScannerModel
Julian Zhou created HBASE-8685: -- Summary: [REST] Minor fix to XMLSchema.xsd and ScannerModel Key: HBASE-8685 URL: https://issues.apache.org/jira/browse/HBASE-8685 Project: HBase Issue Type: Improvement Components: REST Affects Versions: 0.95.0, 0.98.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.1, 0.95.2, 0.95.0 Some minor fix to XMLSchema.xsd to resolve the XML schema validation failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8685) [REST] Minor fix to XMLSchema.xsd and ScannerModel
[ https://issues.apache.org/jira/browse/HBASE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8685: --- Attachment: 8685-trunk-0.95.patch [REST] Minor fix to XMLSchema.xsd and ScannerModel -- Key: HBASE-8685 URL: https://issues.apache.org/jira/browse/HBASE-8685 Project: HBase Issue Type: Improvement Components: REST Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8685-trunk-0.95.patch Some minor fix to XMLSchema.xsd to resolve the XML schema validation failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8685) [REST] Minor fix to XMLSchema.xsd and ScannerModel
[ https://issues.apache.org/jira/browse/HBASE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8685: --- Assignee: Julian Zhou [REST] Minor fix to XMLSchema.xsd and ScannerModel -- Key: HBASE-8685 URL: https://issues.apache.org/jira/browse/HBASE-8685 Project: HBase Issue Type: Improvement Components: REST Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8685-trunk-0.95.patch Some minor fix to XMLSchema.xsd to resolve the XML schema validation failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8685) [REST] Minor fix to XMLSchema.xsd and ScannerModel
[ https://issues.apache.org/jira/browse/HBASE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8685: --- Status: Patch Available (was: Open) [REST] Minor fix to XMLSchema.xsd and ScannerModel -- Key: HBASE-8685 URL: https://issues.apache.org/jira/browse/HBASE-8685 Project: HBase Issue Type: Improvement Components: REST Affects Versions: 0.95.0, 0.98.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.1, 0.95.2, 0.95.0 Attachments: 8685-trunk-0.95.patch Some minor fix to XMLSchema.xsd to resolve the XML schema validation failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (HBASE-8685) [REST] Minor fix to XMLSchema.xsd and ScannerModel
[ https://issues.apache.org/jira/browse/HBASE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-8685 started by Julian Zhou. [REST] Minor fix to XMLSchema.xsd and ScannerModel -- Key: HBASE-8685 URL: https://issues.apache.org/jira/browse/HBASE-8685 Project: HBase Issue Type: Improvement Components: REST Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8685-trunk-0.95.patch Some minor fix to XMLSchema.xsd to resolve the XML schema validation failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work stopped] (HBASE-8685) [REST] Minor fix to XMLSchema.xsd and ScannerModel
[ https://issues.apache.org/jira/browse/HBASE-8685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-8685 stopped by Julian Zhou. [REST] Minor fix to XMLSchema.xsd and ScannerModel -- Key: HBASE-8685 URL: https://issues.apache.org/jira/browse/HBASE-8685 Project: HBase Issue Type: Improvement Components: REST Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8685-trunk-0.95.patch Some minor fix to XMLSchema.xsd to resolve the XML schema validation failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8642) [Snapshot] List and delete snapshot by table
[ https://issues.apache.org/jira/browse/HBASE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13672774#comment-13672774 ] Julian Zhou commented on HBASE-8642: Hi, [~mbertozzi], I see that last slide of HBASE-7806 for future, is that to seperate .data and .meta to enable possible file sharing among tables. One byte (256 items could be attached) for each node anchor under .data tree. This could be a new catalog system for hbase. [Snapshot] List and delete snapshot by table Key: HBASE-8642 URL: https://issues.apache.org/jira/browse/HBASE-8642 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8642-trunk-0.95-v0.patch, 8642-trunk-0.95-v1.patch Support list and delete snapshot by table name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8642) [Snapshot] List and delete snapshot by table
[ https://issues.apache.org/jira/browse/HBASE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8642: --- Attachment: 8642-trunk-0.95-v2.patch Updated with new ruby module name. Could we go ahead with this? [Snapshot] List and delete snapshot by table Key: HBASE-8642 URL: https://issues.apache.org/jira/browse/HBASE-8642 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8642-trunk-0.95-v0.patch, 8642-trunk-0.95-v1.patch, 8642-trunk-0.95-v2.patch Support list and delete snapshot by table name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8642) [Snapshot] List and delete snapshot by table
[ https://issues.apache.org/jira/browse/HBASE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671938#comment-13671938 ] Julian Zhou commented on HBASE-8642: Table rename is via cloning snapshot currently (so we rename the table this way, pairwisely we update all mapped snapshots?)? How about the claiming is that listing/deleting snapshot by table name is based on current table name available? For shorter cmd, how about delete_table_snapshot/list_table_snapshot? [Snapshot] List and delete snapshot by table Key: HBASE-8642 URL: https://issues.apache.org/jira/browse/HBASE-8642 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8642-trunk-0.95-v0.patch, 8642-trunk-0.95-v1.patch Support list and delete snapshot by table name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8642) [Snapshot] List and delete snapshot by table
[ https://issues.apache.org/jira/browse/HBASE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13671940#comment-13671940 ] Julian Zhou commented on HBASE-8642: Yeah, RDBMS has object (database, tablespace, table, column, etc.) id in catalog, which make external name changable and transparent to system. Is it possible to using id (shorter) instead of original name bytes in ROOT/META? Just a question, this involve lots of changes to current HBase. [Snapshot] List and delete snapshot by table Key: HBASE-8642 URL: https://issues.apache.org/jira/browse/HBASE-8642 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8642-trunk-0.95-v0.patch, 8642-trunk-0.95-v1.patch Support list and delete snapshot by table name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8642) [Snapshot] List and delete snapshot by table
[ https://issues.apache.org/jira/browse/HBASE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670385#comment-13670385 ] Julian Zhou commented on HBASE-8642: Hi [~mbertozzi], I was just adding shell support just now. Curious about rename_snapshot could not work? looks like HBaseAdmin has no #renameSnapshot? [Snapshot] List and delete snapshot by table Key: HBASE-8642 URL: https://issues.apache.org/jira/browse/HBASE-8642 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8642-trunk-0.95-v0.patch Support list and delete snapshot by table name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8642) [Snapshot] List and delete snapshot by table
[ https://issues.apache.org/jira/browse/HBASE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670397#comment-13670397 ] Julian Zhou commented on HBASE-8642: Oh, thanks [~mbertozzi] for pointing. I should do a search first.. ok, may not include into this stream? Another question is that why not define more functions in admin module pointing to e.g. HBaseAdmin#listSnapshots(regex), #deleteSnapshots(regex).. then shell/command/*.rb module could invoke them directly, currently, list_snapshots module has its own regex processing logic implemented? xxx.to_java_bytes is mandatory for ruby-java method call? [Snapshot] List and delete snapshot by table Key: HBASE-8642 URL: https://issues.apache.org/jira/browse/HBASE-8642 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8642-trunk-0.95-v0.patch Support list and delete snapshot by table name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8642) [Snapshot] List and delete snapshot by table
[ https://issues.apache.org/jira/browse/HBASE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8642: --- Attachment: 8642-trunk-0.95-v1.patch Hi, [~mbertozzi], applied the changes. Could you help review? Thanks~ [Snapshot] List and delete snapshot by table Key: HBASE-8642 URL: https://issues.apache.org/jira/browse/HBASE-8642 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8642-trunk-0.95-v0.patch, 8642-trunk-0.95-v1.patch Support list and delete snapshot by table name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8642) [Snapshot] List and delete snapshot by table
Julian Zhou created HBASE-8642: -- Summary: [Snapshot] List and delete snapshot by table Key: HBASE-8642 URL: https://issues.apache.org/jira/browse/HBASE-8642 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.95.0, 0.98.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.1, 0.95.2, 0.95.0 Support list and delete snapshot by table name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8642) [Snapshot] List and delete snapshot by table
[ https://issues.apache.org/jira/browse/HBASE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8642: --- Attachment: 8642-trunk-0.95-v0.patch [Snapshot] List and delete snapshot by table Key: HBASE-8642 URL: https://issues.apache.org/jira/browse/HBASE-8642 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8642-trunk-0.95-v0.patch Support list and delete snapshot by table name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8642) [Snapshot] List and delete snapshot by table
[ https://issues.apache.org/jira/browse/HBASE-8642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670072#comment-13670072 ] Julian Zhou commented on HBASE-8642: Thanks for review, [~mbertozzi] and [~jesse_yates]. 1) for the logic inside deleteSnapshotsByTable(), I was just copying from #deleteSnapshots(final Pattern pattern), is it ok? 2) locally applied the comment changes; 3) for shell support, I just studied the 6353. Seems there are 2 options: a) add new list_snapshots_by_table.rb and delete_snapshot_by_table.rb to separate the case from regex based operation; b) still in list_snapshots.rb and delete_snapshot.rb, but add -table option to branch out from regex based operation path. seems that delete_snapshot.rb has no logic for regex based operation currently, will we also support it in this stream? [Snapshot] List and delete snapshot by table Key: HBASE-8642 URL: https://issues.apache.org/jira/browse/HBASE-8642 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.1, 0.95.2 Attachments: 8642-trunk-0.95-v0.patch Support list and delete snapshot by table name. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7404) Bucket Cache:A solution about CMS,Heap Fragment and Big Cache on HBASE
[ https://issues.apache.org/jira/browse/HBASE-7404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667653#comment-13667653 ] Julian Zhou commented on HBASE-7404: Hi, [~zjushch], nice feature, I am going to enable and try on our cluster. May I consult about 2 question? 1) the benchmark result in your document is based on pointing IOEngine to Fusion-IO SSD or common HDD? 2) any intelligent dynamic switching logic between LRU block cache and bucket cache based on hit ratio or other I/O pattern? Thanks~ Bucket Cache:A solution about CMS,Heap Fragment and Big Cache on HBASE -- Key: HBASE-7404 URL: https://issues.apache.org/jira/browse/HBASE-7404 Project: HBase Issue Type: New Feature Affects Versions: 0.94.3 Reporter: chunhui shen Assignee: chunhui shen Fix For: 0.95.0 Attachments: 7404-trunk-v10.patch, 7404-trunk-v11.patch, 7404-trunk-v12.patch, 7404-trunk-v13.patch, 7404-trunk-v13.txt, 7404-trunk-v14.patch, BucketCache.pdf, hbase-7404-94v2.patch, HBASE-7404-backport-0.94.patch, hbase-7404-trunkv2.patch, hbase-7404-trunkv9.patch, Introduction of Bucket Cache.pdf First, thanks @neil from Fusion-IO share the source code. Usage: 1.Use bucket cache as main memory cache, configured as the following: –hbase.bucketcache.ioengine heap –hbase.bucketcache.size 0.4 (size for bucket cache, 0.4 is a percentage of max heap size) 2.Use bucket cache as a secondary cache, configured as the following: –hbase.bucketcache.ioengine file:/disk1/hbase/cache.data(The file path where to store the block data) –hbase.bucketcache.size 1024 (size for bucket cache, unit is MB, so 1024 means 1GB) –hbase.bucketcache.combinedcache.enabled false (default value being true) See more configurations from org.apache.hadoop.hbase.io.hfile.CacheConfig and org.apache.hadoop.hbase.io.hfile.bucket.BucketCache What's Bucket Cache? It could greatly decrease CMS and heap fragment by GC It support a large cache space for High Read Performance by using high speed disk like Fusion-io 1.An implementation of block cache like LruBlockCache 2.Self manage blocks' storage position through Bucket Allocator 3.The cached blocks could be stored in the memory or file system 4.Bucket Cache could be used as a mainly block cache(see CombinedBlockCache), combined with LruBlockCache to decrease CMS and fragment by GC. 5.BucketCache also could be used as a secondary cache(e.g. using Fusionio to store block) to enlarge cache space How about SlabCache? We have studied and test SlabCache first, but the result is bad, because: 1.SlabCache use SingleSizeCache, its use ratio of memory is low because kinds of block size, especially using DataBlockEncoding 2.SlabCache is uesd in DoubleBlockCache, block is cached both in SlabCache and LruBlockCache, put the block to LruBlockCache again if hit in SlabCache , it causes CMS and heap fragment don't get any better 3.Direct heap performance is not good as heap, and maybe cause OOM, so we recommend using heap engine See more in the attachment and in the patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8533: --- Affects Version/s: (was: 0.94.3) 0.95.0 [REST] HBaseAdmin does not ride over cluster restart Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.98.0, 0.95.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.94.3, 0.98.0 Attachments: 8533-trunk-v1.patch, hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8533: --- Fix Version/s: (was: 0.94.3) 0.95.0 [REST] HBaseAdmin does not ride over cluster restart Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.98.0, 0.95.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0 Attachments: 8533-trunk-v1.patch, hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8533: --- Attachment: 8533-0.95-v1.patch [REST] HBaseAdmin does not ride over cluster restart Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.98.0, 0.95.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0 Attachments: 8533-0.95-v1.patch, 8533-trunk-v1.patch, hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) [Webui] Bootstrap based webui compatibility for IE.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Affects Version/s: 0.95.0 [Webui] Bootstrap based webui compatibility for IE. --- Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: hbase-8532_v0.patch, webui-IE-error-apos;.png, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) [Webui] Bootstrap based webui compatibility for IE.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Fix Version/s: 0.95.0 0.95.2 [Webui] Bootstrap based webui compatibility for IE. --- Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.2 Attachments: hbase-8532_v0.patch, webui-IE-error-apos;.png, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667324#comment-13667324 ] Julian Zhou commented on HBASE-8533: [~te...@apache.org] thanks, the same patch also works for 0.95, which is with new refactored HConnectionManager logic. [REST] HBaseAdmin does not ride over cluster restart Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.98.0, 0.95.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0 Attachments: 8533-trunk-v1.patch, hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667332#comment-13667332 ] Julian Zhou commented on HBASE-8533: Hi, [~apurtell], could you help review the patch? The logic for trunk and 0.95 are the same. Thanks~ [REST] HBaseAdmin does not ride over cluster restart Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.98.0, 0.95.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0 Attachments: 8533-0.95-v1.patch, 8533-trunk-v1.patch, hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13667333#comment-13667333 ] Julian Zhou commented on HBASE-8533: [~apurtell], the patch does not change the logic to create an HBaseAdmin on demand, still keep the singleton mode for rest servlet client. Just recovered the zk connection from the 1st failure of HConnectionManager's getMaster retry to make HBaseAdmin ride over cluster restart. [REST] HBaseAdmin does not ride over cluster restart Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.98.0, 0.95.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0 Attachments: 8533-0.95-v1.patch, 8533-trunk-v1.patch, hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) [Webui] Bootstrap based webui compatibility for IE.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Attachment: 8532-trunk-0.95-v1.patch Hi, [~eclark], could you help review the patch? This one also includes some refinement and format correction on the pages. Webkit based and IE 8 browsers have been tested in production environment. The patch is for trunk and 0.95 both. Thanks~ [Webui] Bootstrap based webui compatibility for IE. --- Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.2 Attachments: 8532-trunk-0.95-v1.patch, hbase-8532_v0.patch, webui-IE-error-apos;.png, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) [Webui] Bootstrap based webui compatibility for IE and also fix some page format issues.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Summary: [Webui] Bootstrap based webui compatibility for IE and also fix some page format issues. (was: [Webui] Bootstrap based webui compatibility for IE.) [Webui] Bootstrap based webui compatibility for IE and also fix some page format issues. Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.95.0, 0.95.2 Attachments: 8532-trunk-0.95-v1.patch, hbase-8532_v0.patch, webui-IE-error-apos;.png, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8566) Master-Slave replication: truncate action isn't sent over to slave cluster and cause data inconsistency
[
https://issues.apache.org/jira/browse/HBASE-8566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13660475#comment-13660475
]
Julian Zhou commented on HBASE-8566:
I've seen some solutions based on relational database clusters in active/active
or active/passive mode support DDL sync and DML high availability. They are
doing this in application level. HBaseAdmin seems a good place to play this.
Master-Slave replication: truncate action isn't sent over to slave cluster
and cause data inconsistency
---
Key: HBASE-8566
URL: https://issues.apache.org/jira/browse/HBASE-8566
Project: HBase
Issue Type: Bug
Components: Replication
Affects Versions: 0.94.3
Environment: two 2-nodes clusters setup as Master and Slave for
replication of table 'usertable'
Reporter: Demai Ni
Priority: Minor
after successfully setup the replcation. put some rows into 'usertable' ,
At Master cluster
$truncate 'usertable'
The truncate(or mass delete from user perspective) request isn't sent over to
slave cluster.
From internal, the truncate is 'disable', 'drop' and 'create'. Such
operations are not designed for replication. However, from external/user
perspective, this is a 'delete everything' operation, which should be part of
the replication.
This JIRA is to add this support
---
additional information. I did a few loads using YCSB into 'usertable', with
different # of rows(from 1000 to 10). And did truncate a couple times in
between. Then the slave cluster began to throw errors:
{code:title=count failed on slave cluster|borderStyle=solid}
ERROR: org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after
attempts=7, exceptions:
Thu May 16 15:00:13 PDT 2013,
org.apache.hadoop.hbase.client.ScannerCallable@4c474c47,
java.net.ConnectException: Connection refused
Thu May 16 15:00:32 PDT 2013,
org.apache.hadoop.hbase.client.ScannerCallable@4c474c47,
org.apache.hadoop.hbase.client.NoServerForRegionException: Unable to find
region for usertable,,99 after 7 tries.
Thu May 16 15:00:51 PDT 2013,
org.apache.hadoop.hbase.client.ScannerCallable@4c474c47,
org.apache.hadoop.hbase.client.NoServerForRegionException: Unable to find
region for usertable,,99 after 7 tries.
Thu May 16 15:01:11 PDT 2013,
org.apache.hadoop.hbase.client.ScannerCallable@4c474c47,
org.apache.hadoop.hbase.client.NoServerForRegionException: Unable to find
region for usertable,,99 after 7 tries.
{code}
The regionserver log of slave cluster throws :
{code:title=regionserver log of slave cluster|borderStyle=solid}
2013-05-16 14:59:59,655 ERROR
org.apache.hadoop.hbase.replication.regionserver.ReplicationSink: Unable to
accept edit because:
java.io.IOException: java.lang.InterruptedException
at
org.apache.hadoop.hbase.replication.regionserver.ReplicationSink.batch(ReplicationSink.java:220)
at
org.apache.hadoop.hbase.replication.regionserver.ReplicationSink.replicateEntries(ReplicationSink.java:154)
at
org.apache.hadoop.hbase.replication.regionserver.Replication.replicateLogEntries(Replication.java:140)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.replicateLogEntries(HRegionServer.java:3797)
at sun.reflect.GeneratedMethodAccessor29.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at
org.apache.hadoop.hbase.ipc.WritableRpcEngine$Server.call(WritableRpcEngine.java:364)
at
org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1426)
Caused by: java.lang.InterruptedException
at java.lang.Thread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:853)
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatchCallback(HConnectionManager.java:1507)
at
org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.processBatch(HConnectionManager.java:1400)
at org.apache.hadoop.hbase.client.HTable.batch(HTable.java:699)
at
org.apache.hadoop.hbase.replication.regionserver.ReplicationSink.batch(ReplicationSink.java:217)
... 8 more
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8533: --- Attachment: hbase-8533-trunk-v0.patch Using rest client to recreate, there are 2 scenarios, steps could be: -- Scenario A: request after cluster restart 1) start cluster; 2) start rest at a port 8000; 3) stop the whole cluster (including zk); 4) start the whole cluster again; 5) request http://ip:8000/ to get table list. == waiting for 10 getMaster retry (HConnectionManager), each retry with 3 zk connection retries by RecoverableZooKeeper. 10 getMaster retry failed, then Unavailable as rest response; -- Scenario B: rest request between stop and start cluster 1) start cluster; 2) start rest at a port 8000; 3) stop the whole cluster (including zk); 4) request http://ip:8000/ to get table list == same retry logic as A.. 5) start the whole cluster again. == rest in 4) will kill old zk connection for HConnection and rebuild new zk connection: - 2013-05-16 17:04:09,037 INFO [79168696@qtp-2077588437-0] org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper: Closing dead ZooKeeper connection, session was: 0x0 2013-05-16 17:04:09,037 DEBUG [79168696@qtp-2077588437-0] org.apache.zookeeper.ZooKeeper: Closing session: 0x0 2013-05-16 17:04:09,037 DEBUG [79168696@qtp-2077588437-0] org.apache.zookeeper.ClientCnxn: Closing client for session: 0x0 2013-05-16 17:04:09,131 DEBUG [79168696@qtp-2077588437-0] org.apache.zookeeper.ClientCnxn: Disconnecting client for session: 0x0 2013-05-16 17:04:09,131 INFO [79168696@qtp-2077588437-0] org.apache.zookeeper.ZooKeeper: Session: 0x0 closed 2013-05-16 17:04:09,131 INFO [79168696@qtp-2077588437-0] org.apache.zookeeper.ZooKeeper: Initiating client connection, connectString=localhost:2181 sessionTimeout=18 watcher=hconnection-0x43724372-0x13eac8abdbc0003-0x13eac917e7e0003-0x13eac917e7e0004 - Then, response successfully with table list. [REST] HBaseAdmin does not ride over cluster restart Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.94.3, 0.98.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.94.3, 0.98.0 Attachments: hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13659394#comment-13659394 ] Julian Zhou commented on HBASE-8533: A correction for previous comment: about scenario B, that's the behavior with the patch, if without patch, rest will also get Unavailable after 10 getMaster retries finally. [REST] HBaseAdmin does not ride over cluster restart Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.94.3, 0.98.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.94.3, 0.98.0 Attachments: hbase-8533-trunk-v0.patch For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[
https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13657168#comment-13657168
]
Julian Zhou commented on HBASE-8533:
For the topic of HBaseAdmin riding over cluster restart, looks like the main
logic is in HConnectionManager.
For this rest scenario, at the very first restart of hbase service after rest
started (no actual hbase admin rpc call happened yet),
#isKeepAliveMasterConnectedAndRunning return false since
MasterMonitorServiceState's stub is null (has not been built from protobuf via
a RPC operation), otherwise MasterMonitorServiceState.isMasterRunning() will
throw protobuf's ServiceException, then will make new protobuf BlockingStub via
#makeStub().
There is 2 rounds of retries for HBaseAdmin's HConnection trying to invoke
master services if master is not running:
1) RecoverableZooKeeper retries 3 times if ZooKeeperWatcher met
KeeperException.CONNECTIONLOSS;
2) in #makeStub(), there are 10 getMaster retries if any exception caught from
ZooKeeper connection.
I just tried to modify HConnectionImplementation#checkIfBaseNodeAvailable to
throw the KeeperException with CONNECTIONLOSS out caught from
ZKUtil.checkExists instead of throwing MasterNotRunningException out, then in
#makeStub, adding this part
...
try {
Thread.sleep(pauseTime);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RuntimeException(
Thread was interrupted while trying to connect to
master., e);
}
// - added for reconnecting to ZK due to connection
loss caused by master restart -- Begin
if (exceptionCaught instanceof KeeperException) {
if (((KeeperException) exceptionCaught).code() ==
KeeperException.Code.CONNECTIONLOSS) {
try {
getKeepAliveZooKeeperWatcher().reconnectAfterExpiration();
} catch (Exception e) {
LOG.error(Encountered unexpected exception while trying
+ to recover from ZooKeeper connection loss., e);
}
}
}
// - added for reconnecting to ZK due to connection
loss caused by master restart -- End
} else {
// Enough tries, we stop now
...
Then rest process could get reconnect to zk service via the same configuration
after master restarted.
[REST] HBaseAdmin does not ride over cluster restart
Key: HBASE-8533
URL: https://issues.apache.org/jira/browse/HBASE-8533
Project: HBase
Issue Type: Improvement
Components: REST, scripts
Affects Versions: 0.94.3, 0.98.0
Reporter: Julian Zhou
Priority: Minor
Fix For: 0.94.3, 0.98.0
For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94),
org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first
explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 )
for application running. Here is a scenario, sometimes, HBase cluster are
stopped/started for maintanence, but rest is a seperated standalone process,
which binds the HBaseAdmin at construction method.
HBase stop/start cause this binding lost for existing rest servlet. Rest
servlet still exist to trying on old bound HBaseAdmin until a long time
duration later with an Unavailable caught via an IOException caught in
such as RootResource.
Could we pairwise the HBase service with HBase rest service with some
start/stop options? since seems no reason to still keep the rest servlet
process after HBase stopped? When HBase restarts, original rest service could
not resume to bind to the new HBase service via its old HBaseAdmin reference?
So may we stop the rest when hbase stopped, or even if hbase was killed by
acident, restart hbase with rest option could detect the old rest process,
kill it and start to bind a new one?
From this point of view, application rely on rest api in previous scenario
could immediately detect it when setting up http connection session instead
of wasting a long time to fail back from IOException with Unavailable from
rest servlet.
Put current options from the discussion history here from Andrew, Stack and
Jean-Daniel,
1) create an HBaseAdmin on demand in rest servlet instead of keeping
singleton instance; (another possible enhancement for HBase client: automatic
reconnection of an open HBaseAdmin handle after a cluster bounce?)
2) pairwise the rest webapp with hbase webui so the rest is always on with
HBase serive;
3) add an option for rest service (such as HBASE_MANAGES_REST) in
[jira] [Commented] (HBASE-8533) [REST] HBaseAdmin does not ride over cluster restart
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13658077#comment-13658077 ] Julian Zhou commented on HBASE-8533: Hi [~ted_yu], looks like this will benefit all clients using HBaseAdmin besides rest to ride over cluster restart. I will attach the patch after I've done local testing. And just now, there are some new commits changing HConnectionManager, added Registry for cluster information. I need to base on that. Thanks~ [REST] HBaseAdmin does not ride over cluster restart Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.94.3, 0.98.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.94.3, 0.98.0 For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8532) Bootstrap based webui compatibility for IE.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13655792#comment-13655792 ] Julian Zhou commented on HBASE-8532: Hi, [~jmspaggi], thanks if having a try on the patch on the trunk for IE 7. Feel that documenting the browsers supported should make sense for release. Bootstrap based webui compatibility for IE. --- Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: hbase-8532_v0.patch, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) [Webui] Bootstrap based webui compatibility for IE.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Summary: [Webui] Bootstrap based webui compatibility for IE. (was: Bootstrap based webui compatibility for IE.) [Webui] Bootstrap based webui compatibility for IE. --- Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: hbase-8532_v0.patch, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) [Webui] Bootstrap based webui compatibility for IE.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Attachment: webui-IE-error-apos;.png [Webui] Bootstrap based webui compatibility for IE. --- Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: hbase-8532_v0.patch, webui-IE-error-apos;.png, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8532) [Webui] Bootstrap based webui compatibility for IE.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656065#comment-13656065 ] Julian Zhou commented on HBASE-8532: IETester(http://www.my-debugbar.com/wiki/IETester/HomePage) is a tool for testing page in different IE versions. Seems there still got css rendering issue in IE 9 in standard mode. There is another issue for IE 8 and older versions. IE 8 and older versions could not recognize apos; as '. So we should use entity code #039; instead for '. This issue is introduced by escapeXML() function added in .jsp pages. excapeXML will convert the ' to apos;. But in some way, may need to convert to #039; for the case of IE 8 (IE 9 looks like already support to recognize apos;). [Webui] Bootstrap based webui compatibility for IE. --- Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: hbase-8532_v0.patch, webui-IE-error-apos;.png, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) Fix bootstrap based webui to be compatible in IE browser.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Attachment: webui-IE-error.png This is a master status page sample that has layout/style issue in IE 8/9. Fix bootstrap based webui to be compatible in IE browser. - Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html at the beginning of all jamon html/jsp templates to fix it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) Bootstrap based webui compatibility across browsers (IE, Firefox, Chrome, etc.).
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Summary: Bootstrap based webui compatibility across browsers (IE, Firefox, Chrome, etc.). (was: Fix bootstrap based webui to be compatible in IE browser.) Bootstrap based webui compatibility across browsers (IE, Firefox, Chrome, etc.). Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html at the beginning of all jamon html/jsp templates to fix it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) Bootstrap based webui compatibility across browsers (IE, Firefox, Chrome, etc.).
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Description: HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. was:HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html at the beginning of all jamon html/jsp templates to fix it. Bootstrap based webui compatibility across browsers (IE, Firefox, Chrome, etc.). Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) Bootstrap based webui compatibility across browsers (IE, Firefox, Chrome, etc.).
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Description: HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. was: HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. Bootstrap based webui compatibility across browsers (IE, Firefox, Chrome, etc.). Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: hbase-8532_v0.patch, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) Bootstrap based webui compatibility across browsers (IE, Firefox, Chrome, etc.).
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Attachment: hbase-8532_v0.patch Bootstrap based webui compatibility across browsers (IE, Firefox, Chrome, etc.). Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: hbase-8532_v0.patch, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8532) Bootstrap based webui compatibility for IE.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8532: --- Summary: Bootstrap based webui compatibility for IE. (was: Bootstrap based webui compatibility across browsers (IE, Firefox, Chrome, etc.).) Bootstrap based webui compatibility for IE. --- Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: hbase-8532_v0.patch, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8532) Bootstrap based webui compatibility for IE.
[ https://issues.apache.org/jira/browse/HBASE-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13655535#comment-13655535 ] Julian Zhou commented on HBASE-8532: Hi Jean-Marc, Yes, the issue is for IE, so added conditional DOCTYPE for IE. I only got IE 8/9, could not find IE version older than 7 (including 7) :-(. Maybe that's the case for most of PC users. Other browser works fine including Firefox 20.0.1, Chrome 26.0.1410.64 (other browsers with Webkit engine should be ok as well), Opera 12.15, Safari 5.1.9. Bootstrap based webui compatibility for IE. --- Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 Attachments: hbase-8532_v0.patch, webui-IE-error.png HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html ... at the beginning of all jamon html/jsp templates to fix it. Seems HBase-2110 had a work to comment out the DOCTYPE for all .jsp to make the browser run the pages in Quirks mode (http://en.wikipedia.org/wiki/Quirks_mode) due to jetty issue at that time? To support the compatibility of webui across browsers (IE/Firefox/Chrome, etc.), there are some guidelines for choosing rendering the page under standard mode or quirk mode: http://en.wikipedia.org/wiki/Quirks_mode http://hsivonen.iki.fi/doctype/ According to document, !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; has the most extensive compatibility even for HTML 5. According to my test, add this could make webui works in IE (standard mode), while Firefox could not work well with styles. Looks like if in Firefox, we still need the quirk mode (no DOCTYPE declaration). So just adding conditional DOCTYPE declaration for IE, !--[if IE] !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; ![endif]-- this could make webui works for both IE and Firefox, also for Chrome and other browsers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8533) Pairwise HBase rest service with HBase serivce.
Julian Zhou created HBASE-8533: -- Summary: Pairwise HBase rest service with HBase serivce. Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.94.3, 0.98.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.94.3 For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8533) Pairwise HBase rest service with HBase serivce.
[ https://issues.apache.org/jira/browse/HBASE-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8533: --- Description: For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Put current options from the discussion history here from Andrew, Stack and Jean-Daniel, 1) create an HBaseAdmin on demand in rest servlet instead of keeping singleton instance; (another possible enhancement for HBase client: automatic reconnection of an open HBaseAdmin handle after a cluster bounce?) 2) pairwise the rest webapp with hbase webui so the rest is always on with HBase serive; 3) add an option for rest service (such as HBASE_MANAGES_REST) in hbase-env.sh, set HBASE_MANAGES_REST to true, the scripts will start/stop the REST server. was: For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the rest when hbase stopped, or even if hbase was killed by acident, restart hbase with rest option could detect the old rest process, kill it and start to bind a new one? From this point of view, application rely on rest api in previous scenario could immediately detect it when setting up http connection session instead of wasting a long time to fail back from IOException with Unavailable from rest servlet. Pairwise HBase rest service with HBase serivce. --- Key: HBASE-8533 URL: https://issues.apache.org/jira/browse/HBASE-8533 Project: HBase Issue Type: Improvement Components: REST, scripts Affects Versions: 0.94.3, 0.98.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.94.3, 0.98.0 For Restful servlet (org.apache.hadoop.hbase.rest.Main (0.94), org.apache.hadoop.hbase.rest.RESTServer (trunk)) on Jetty, we need to first explicitly start the service (% ./bin/hbase-daemon.sh start rest -p 8000 ) for application running. Here is a scenario, sometimes, HBase cluster are stopped/started for maintanence, but rest is a seperated standalone process, which binds the HBaseAdmin at construction method. HBase stop/start cause this binding lost for existing rest servlet. Rest servlet still exist to trying on old bound HBaseAdmin until a long time duration later with an Unavailable caught via an IOException caught in such as RootResource. Could we pairwise the HBase service with HBase rest service with some start/stop options? since seems no reason to still keep the rest servlet process after HBase stopped? When HBase restarts, original rest service could not resume to bind to the new HBase service via its old HBaseAdmin reference? So may we stop the
[jira] [Created] (HBASE-8532) Fix bootstrap based webui to be compatible in IE browser.
Julian Zhou created HBASE-8532: -- Summary: Fix bootstrap based webui to be compatible in IE browser. Key: HBASE-8532 URL: https://issues.apache.org/jira/browse/HBASE-8532 Project: HBase Issue Type: Bug Components: UI Affects Versions: 0.98.0, 0.95.2 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.98.0 HBASE-7425 brings bootstrap based webui to hbase. While trying on trunk version, Firefox works well, but IE 8/9 layout and style look strange due to compatibility issue. Add !DOCTYPE html at the beginning of all jamon html/jsp templates to fix it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8400) Load coprocessor jar from various protocols (HTTP, HTTPS, FTP, etc.)
Julian Zhou created HBASE-8400: -- Summary: Load coprocessor jar from various protocols (HTTP, HTTPS, FTP, etc.) Key: HBASE-8400 URL: https://issues.apache.org/jira/browse/HBASE-8400 Project: HBase Issue Type: Improvement Components: Coprocessors Affects Versions: 0.94.3, 0.98.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.98.0, 0.94.3 In some application testing and production environment, after developed coprocessors and generated jars, currently we need to transfer them to hdfs first, then specify the URI in table descriptor to point to HDFS compatible addresses of jars. Common used HTTP/HTTPS/FTP or other protocols were not supported yet? To save time and make the life easier without transferring from http/ftp or other servers, just modified the CoprocessorHost to use http/ftp url connection (http and ftp servers are the most cases need to be support) to stream jars to coprocessor jar spaces automatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8400) Load coprocessor jar from various protocols (HTTP, HTTPS, FTP, etc.)
[ https://issues.apache.org/jira/browse/HBASE-8400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8400: --- Assignee: Julian Zhou Load coprocessor jar from various protocols (HTTP, HTTPS, FTP, etc.) Key: HBASE-8400 URL: https://issues.apache.org/jira/browse/HBASE-8400 Project: HBase Issue Type: Improvement Components: Coprocessors Affects Versions: 0.94.3, 0.98.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.3, 0.98.0 In some application testing and production environment, after developed coprocessors and generated jars, currently we need to transfer them to hdfs first, then specify the URI in table descriptor to point to HDFS compatible addresses of jars. Common used HTTP/HTTPS/FTP or other protocols were not supported yet? To save time and make the life easier without transferring from http/ftp or other servers, just modified the CoprocessorHost to use http/ftp url connection (http and ftp servers are the most cases need to be support) to stream jars to coprocessor jar spaces automatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8400) Load coprocessor jar from various protocols (HTTP, HTTPS, FTP, etc.)
[ https://issues.apache.org/jira/browse/HBASE-8400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13640038#comment-13640038 ] Julian Zhou commented on HBASE-8400: Thanks Andrew for pointing and connecting. Just studied the 8327's patch. Looks like the consolidation in it mainly located in CoprocessorClassLoader. CoprocessorHost invokes CoprocessorClassLoader#getClassLoader, in which, when #init, it invokes #copyToLocalFile to copy the jar to local first, then do #addURL for both jar or jar entries in it if any. Could we be one of the options as below: 1) in CoprocessorClassLoader#init, check the scheme in the passed in path, if http/https/ftp, then use http/ftp connection to fetch remote jars streaming to local first, if not, still goes #copyToLocalFile, later logic remains unchanged. (In my testing environment, I go this way currently); 2) in CoprocessorClassLoader#init, check the scheme in the passed in path, if http/https/ftp, #addURL of it directly for network loading, which would not keep a local copy in coprocessor jar space at runtime. In this approach, logic of getting jar entries within the parent jar would not be support? What's your idea for these options or other options? Thanks~ Load coprocessor jar from various protocols (HTTP, HTTPS, FTP, etc.) Key: HBASE-8400 URL: https://issues.apache.org/jira/browse/HBASE-8400 Project: HBase Issue Type: Improvement Components: Coprocessors Affects Versions: 0.94.3, 0.98.0 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.94.3, 0.98.0 In some application testing and production environment, after developed coprocessors and generated jars, currently we need to transfer them to hdfs first, then specify the URI in table descriptor to point to HDFS compatible addresses of jars. Common used HTTP/HTTPS/FTP or other protocols were not supported yet? To save time and make the life easier without transferring from http/ftp or other servers, just modified the CoprocessorHost to use http/ftp url connection (http and ftp servers are the most cases need to be support) to stream jars to coprocessor jar spaces automatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-8199) Eliminate exception for ExportSnapshot against the null table snapshot (with no data in)
Julian Zhou created HBASE-8199: -- Summary: Eliminate exception for ExportSnapshot against the null table snapshot (with no data in) Key: HBASE-8199 URL: https://issues.apache.org/jira/browse/HBASE-8199 Project: HBase Issue Type: Bug Components: snapshots Affects Versions: 0.94.6, 0.95.0, 0.94.7 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.95.0, 0.94.6 In the test environment, when snapshoting the null table (with no data), snapshot artifact can be generated successfully which snapshot meta data, while there is no CF data under region dir. Then when exporting this null snapshot via ExportSnapshot, java.io.IOException: No input paths specified in job occurred, which affects the normal application flow. But seems snapshot for null table also makes sense just with the meta information (.snapshot/), although .archive/ does not show up. Later snapshot restore seems work from this dummy snapshot artifact with no CF data. Just eliminate exception for ExportSnapshot against the null table snapshot to make application work through. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8199) Eliminate exception for ExportSnapshot against the null table snapshot (with no data in)
[ https://issues.apache.org/jira/browse/HBASE-8199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8199: --- Status: Patch Available (was: Open) Eliminate exception for ExportSnapshot against the null table snapshot (with no data in) Key: HBASE-8199 URL: https://issues.apache.org/jira/browse/HBASE-8199 Project: HBase Issue Type: Bug Components: snapshots Affects Versions: 0.94.6, 0.95.0, 0.94.7 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.95.0, 0.94.6 In the test environment, when snapshoting the null table (with no data), snapshot artifact can be generated successfully which snapshot meta data, while there is no CF data under region dir. Then when exporting this null snapshot via ExportSnapshot, java.io.IOException: No input paths specified in job occurred, which affects the normal application flow. But seems snapshot for null table also makes sense just with the meta information (.snapshot/), although .archive/ does not show up. Later snapshot restore seems work from this dummy snapshot artifact with no CF data. Just eliminate exception for ExportSnapshot against the null table snapshot to make application work through. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8199) Eliminate exception for ExportSnapshot against the null table snapshot (with no data in)
[ https://issues.apache.org/jira/browse/HBASE-8199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8199: --- Attachment: HBASE-8199-0.94.patch Eliminate exception for ExportSnapshot against the null table snapshot (with no data in) Key: HBASE-8199 URL: https://issues.apache.org/jira/browse/HBASE-8199 Project: HBase Issue Type: Bug Components: snapshots Affects Versions: 0.95.0, 0.94.6, 0.94.7 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.95.0, 0.94.6 Attachments: HBASE-8199-0.94.patch In the test environment, when snapshoting the null table (with no data), snapshot artifact can be generated successfully which snapshot meta data, while there is no CF data under region dir. Then when exporting this null snapshot via ExportSnapshot, java.io.IOException: No input paths specified in job occurred, which affects the normal application flow. But seems snapshot for null table also makes sense just with the meta information (.snapshot/), although .archive/ does not show up. Later snapshot restore seems work from this dummy snapshot artifact with no CF data. Just eliminate exception for ExportSnapshot against the null table snapshot to make application work through. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8199) Eliminate exception for ExportSnapshot against the null table snapshot (with no data in)
[ https://issues.apache.org/jira/browse/HBASE-8199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8199: --- Attachment: HBASE-8199-trunk.patch Eliminate exception for ExportSnapshot against the null table snapshot (with no data in) Key: HBASE-8199 URL: https://issues.apache.org/jira/browse/HBASE-8199 Project: HBase Issue Type: Bug Components: snapshots Affects Versions: 0.95.0, 0.94.6, 0.94.7 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.95.0, 0.94.6 Attachments: HBASE-8199-0.94.patch, HBASE-8199-trunk.patch In the test environment, when snapshoting the null table (with no data), snapshot artifact can be generated successfully which snapshot meta data, while there is no CF data under region dir. Then when exporting this null snapshot via ExportSnapshot, java.io.IOException: No input paths specified in job occurred, which affects the normal application flow. But seems snapshot for null table also makes sense just with the meta information (.snapshot/), although .archive/ does not show up. Later snapshot restore seems work from this dummy snapshot artifact with no CF data. Just eliminate exception for ExportSnapshot against the null table snapshot to make application work through. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8199) Eliminate exception for ExportSnapshot against the null table snapshot (with no data in)
[ https://issues.apache.org/jira/browse/HBASE-8199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8199: --- Description: In the test environment, when snapshoting the null table (with no data), snapshot artifact can be generated successfully with snapshot meta data, while there is no CF data under region dir. Then when exporting this null snapshot via ExportSnapshot, java.io.IOException: No input paths specified in job occurred, which affects the normal application flow. But seems snapshot for null table also makes sense just with the meta information (.snapshot/), although .archive/ does not show up. Later snapshot restore seems work from this dummy snapshot artifact with no CF data. Just eliminate exception for ExportSnapshot against the null table snapshot to make application work through. was: In the test environment, when snapshoting the null table (with no data), snapshot artifact can be generated successfully which snapshot meta data, while there is no CF data under region dir. Then when exporting this null snapshot via ExportSnapshot, java.io.IOException: No input paths specified in job occurred, which affects the normal application flow. But seems snapshot for null table also makes sense just with the meta information (.snapshot/), although .archive/ does not show up. Later snapshot restore seems work from this dummy snapshot artifact with no CF data. Just eliminate exception for ExportSnapshot against the null table snapshot to make application work through. Eliminate exception for ExportSnapshot against the null table snapshot (with no data in) Key: HBASE-8199 URL: https://issues.apache.org/jira/browse/HBASE-8199 Project: HBase Issue Type: Bug Components: snapshots Affects Versions: 0.95.0, 0.94.6, 0.94.7 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.95.0, 0.94.6 Attachments: HBASE-8199-0.94.patch, HBASE-8199-trunk.patch In the test environment, when snapshoting the null table (with no data), snapshot artifact can be generated successfully with snapshot meta data, while there is no CF data under region dir. Then when exporting this null snapshot via ExportSnapshot, java.io.IOException: No input paths specified in job occurred, which affects the normal application flow. But seems snapshot for null table also makes sense just with the meta information (.snapshot/), although .archive/ does not show up. Later snapshot restore seems work from this dummy snapshot artifact with no CF data. Just eliminate exception for ExportSnapshot against the null table snapshot to make application work through. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8199) Eliminate exception for ExportSnapshot against the null table snapshot (with no data in)
[ https://issues.apache.org/jira/browse/HBASE-8199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-8199: --- Issue Type: Improvement (was: Bug) Eliminate exception for ExportSnapshot against the null table snapshot (with no data in) Key: HBASE-8199 URL: https://issues.apache.org/jira/browse/HBASE-8199 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.95.0, 0.94.6, 0.94.7 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.95.0, 0.94.6 Attachments: HBASE-8199-0.94.patch, HBASE-8199-trunk.patch In the test environment, when snapshoting the null table (with no data), snapshot artifact can be generated successfully with snapshot meta data, while there is no CF data under region dir. Then when exporting this null snapshot via ExportSnapshot, java.io.IOException: No input paths specified in job occurred, which affects the normal application flow. But seems snapshot for null table also makes sense just with the meta information (.snapshot/), although .archive/ does not show up. Later snapshot restore seems work from this dummy snapshot artifact with no CF data. Just eliminate exception for ExportSnapshot against the null table snapshot to make application work through. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8199) Eliminate exception for ExportSnapshot against the null table snapshot (with no data in)
[ https://issues.apache.org/jira/browse/HBASE-8199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13614741#comment-13614741 ] Julian Zhou commented on HBASE-8199: Thanks, @Matteo and @Jonathan. A bunch of empty tables in the test environment could work through. Eliminate exception for ExportSnapshot against the null table snapshot (with no data in) Key: HBASE-8199 URL: https://issues.apache.org/jira/browse/HBASE-8199 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.95.0, 0.94.6, 0.94.7 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.95.0, 0.94.6 Attachments: HBASE-8199-0.94.patch, HBASE-8199-trunk.patch, HBASE-8199-with-test.patch In the test environment, when snapshoting the null table (with no data), snapshot artifact can be generated successfully with snapshot meta data, while there is no CF data under region dir. Then when exporting this null snapshot via ExportSnapshot, java.io.IOException: No input paths specified in job occurred, which affects the normal application flow. But seems snapshot for null table also makes sense just with the meta information (.snapshot/), although .archive/ does not show up. Later snapshot restore seems work from this dummy snapshot artifact with no CF data. Just eliminate exception for ExportSnapshot against the null table snapshot to make application work through. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8199) Eliminate exception for ExportSnapshot against the null table snapshot (with no data in)
[ https://issues.apache.org/jira/browse/HBASE-8199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13614764#comment-13614764 ] Julian Zhou commented on HBASE-8199: Got it, @Jonathan. I will keep in mind. Eliminate exception for ExportSnapshot against the null table snapshot (with no data in) Key: HBASE-8199 URL: https://issues.apache.org/jira/browse/HBASE-8199 Project: HBase Issue Type: Improvement Components: snapshots Affects Versions: 0.95.0, 0.94.6, 0.94.7 Reporter: Julian Zhou Assignee: Julian Zhou Priority: Minor Fix For: 0.95.0, 0.94.6 Attachments: HBASE-8199-0.94.patch, HBASE-8199-trunk.patch, HBASE-8199-with-test.patch In the test environment, when snapshoting the null table (with no data), snapshot artifact can be generated successfully with snapshot meta data, while there is no CF data under region dir. Then when exporting this null snapshot via ExportSnapshot, java.io.IOException: No input paths specified in job occurred, which affects the normal application flow. But seems snapshot for null table also makes sense just with the meta information (.snapshot/), although .archive/ does not show up. Later snapshot restore seems work from this dummy snapshot artifact with no CF data. Just eliminate exception for ExportSnapshot against the null table snapshot to make application work through. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7552) Pass bufferSize param to FileLinkInputStream constructor within FileLink.open method, and remove unnecessary import packages.
Julian Zhou created HBASE-7552: -- Summary: Pass bufferSize param to FileLinkInputStream constructor within FileLink.open method, and remove unnecessary import packages. Key: HBASE-7552 URL: https://issues.apache.org/jira/browse/HBASE-7552 Project: HBase Issue Type: Bug Components: io Affects Versions: 0.96.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.96.0 There are 2 minor fixes: 1) The call to FileLinkInputStream constructor missed the buffer size param within FileLink.open(final FileSystem fs, int bufferSize) implementation. 2) Removed the unnecessary java pkg import: import java.util.ArrayList; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.hbase.HConstants; import org.apache.hadoop.hbase.util.FSUtils; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7552) Pass bufferSize param to FileLinkInputStream constructor within FileLink.open method, and remove unnecessary import packages.
[ https://issues.apache.org/jira/browse/HBASE-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-7552: --- Status: Patch Available (was: Open) Pass bufferSize param to FileLinkInputStream constructor within FileLink.open method, and remove unnecessary import packages. - Key: HBASE-7552 URL: https://issues.apache.org/jira/browse/HBASE-7552 Project: HBase Issue Type: Bug Components: io Affects Versions: 0.96.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.96.0 Original Estimate: 12h Remaining Estimate: 12h There are 2 minor fixes: 1) The call to FileLinkInputStream constructor missed the buffer size param within FileLink.open(final FileSystem fs, int bufferSize) implementation. 2) Removed the unnecessary java pkg import: import java.util.ArrayList; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.hbase.HConstants; import org.apache.hadoop.hbase.util.FSUtils; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7552) Pass bufferSize param to FileLinkInputStream constructor within FileLink.open method, and remove unnecessary import packages.
[ https://issues.apache.org/jira/browse/HBASE-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-7552: --- Status: Open (was: Patch Available) Pass bufferSize param to FileLinkInputStream constructor within FileLink.open method, and remove unnecessary import packages. - Key: HBASE-7552 URL: https://issues.apache.org/jira/browse/HBASE-7552 Project: HBase Issue Type: Bug Components: io Affects Versions: 0.96.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.96.0 Original Estimate: 12h Remaining Estimate: 12h There are 2 minor fixes: 1) The call to FileLinkInputStream constructor missed the buffer size param within FileLink.open(final FileSystem fs, int bufferSize) implementation. 2) Removed the unnecessary java pkg import: import java.util.ArrayList; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.hbase.HConstants; import org.apache.hadoop.hbase.util.FSUtils; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7552) Pass bufferSize param to FileLinkInputStream constructor within FileLink.open method, and remove unnecessary import packages.
[ https://issues.apache.org/jira/browse/HBASE-7552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-7552: --- Attachment: HBASE-7552.patch Pass bufferSize param to FileLinkInputStream constructor within FileLink.open method, and remove unnecessary import packages. - Key: HBASE-7552 URL: https://issues.apache.org/jira/browse/HBASE-7552 Project: HBase Issue Type: Bug Components: io Affects Versions: 0.96.0 Reporter: Julian Zhou Priority: Minor Fix For: 0.96.0 Attachments: HBASE-7552.patch Original Estimate: 12h Remaining Estimate: 12h There are 2 minor fixes: 1) The call to FileLinkInputStream constructor missed the buffer size param within FileLink.open(final FileSystem fs, int bufferSize) implementation. 2) Removed the unnecessary java pkg import: import java.util.ArrayList; import org.apache.hadoop.conf.Configuration; import org.apache.hadoop.hbase.HConstants; import org.apache.hadoop.hbase.util.FSUtils; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7312) Flatten the invoking to the compare/match methods of KeyValue.java
[ https://issues.apache.org/jira/browse/HBASE-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Zhou updated HBASE-7312: --- Attachment: HBase-7312-TestReport.pdf HBASE-7312 benchmark shows that the improvement is stably fixed at around 2% of scan elapse time. The workload used is HBASE-6923 TestStorePerformance.java. Flatten the invoking to the compare/match methods of KeyValue.java -- Key: HBASE-7312 URL: https://issues.apache.org/jira/browse/HBASE-7312 Project: HBase Issue Type: Improvement Components: Performance Affects Versions: 0.94.2, 0.94.3 Reporter: Julian Zhou Priority: Minor Attachments: HBase-7312-TestReport.pdf Original Estimate: 168h Remaining Estimate: 168h Invoking to some methods in KeyValue may could be short cut. Like KeyComparator.compareColumns - KeyValue.compareColumns, KVComparator.compareColumns - KeyComparator.compareColumns - KeyValue.compareColumns, KeyComparator.compareRows - Bytes.compareTo, KVComparator.matchingRows - Bytes.equals, MetaKeyComparator.compareRowid - Bytes.compareTo, ... etc. Will apply the change, the test the performance difference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6923) Create scanner benchmark
[ https://issues.apache.org/jira/browse/HBASE-6923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13545330#comment-13545330 ] Julian Zhou commented on HBASE-6923: @Todd, Hi Todd, I used you code TestStorePerformance.java for benchmarking HBASE-7312, which showed 2% performance improvement with HBASE-7312 (benchmark report attached). Thanks~ Create scanner benchmark Key: HBASE-6923 URL: https://issues.apache.org/jira/browse/HBASE-6923 Project: HBase Issue Type: Sub-task Reporter: Karthik Ranganathan Assignee: Karthik Ranganathan Attachments: TestStorePerformance.java Create a simple program to benchmark performance/throughput of scanners, and print some results at the end. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HBASE-7312) Flatten the invoking to the compare/match methods of KeyValue.java
Julian Zhou created HBASE-7312: -- Summary: Flatten the invoking to the compare/match methods of KeyValue.java Key: HBASE-7312 URL: https://issues.apache.org/jira/browse/HBASE-7312 Project: HBase Issue Type: Improvement Components: Performance Affects Versions: 0.94.3, 0.94.2 Reporter: Julian Zhou Priority: Minor Fix For: 0.94.3, 0.94.2 Invoking to some methods in KeyValue may could be short cut. Like KeyComparator.compareColumns - KeyValue.compareColumns, KVComparator.compareColumns - KeyComparator.compareColumns - KeyValue.compareColumns, KeyComparator.compareRows - Bytes.compareTo, KVComparator.matchingRows - Bytes.equals, MetaKeyComparator.compareRowid - Bytes.compareTo, ... etc. Will apply the change, the test the performance difference. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7257) Region server group based configuration
[ https://issues.apache.org/jira/browse/HBASE-7257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508474#comment-13508474 ] Julian Zhou commented on HBASE-7257: @Ted, nice group level isolation of the conf parameters, how will this co-work with HBase-4120's table priority across RS groups? Region server group based configuration --- Key: HBASE-7257 URL: https://issues.apache.org/jira/browse/HBASE-7257 Project: HBase Issue Type: Sub-task Reporter: Ted Yu Fix For: 0.96.0 The read/write load pattern would be different across region server groups. It is desirable for each group to have unique configuration parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-7257) Region server group based configuration
[ https://issues.apache.org/jira/browse/HBASE-7257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508505#comment-13508505 ] Julian Zhou commented on HBASE-7257: Thanks @Ted, studying the design and code, thinking that how the rs group assignment w/ seperate conf and w/ table priority would benefit different use cases/client app, also if load balancing is involved. Region server group based configuration --- Key: HBASE-7257 URL: https://issues.apache.org/jira/browse/HBASE-7257 Project: HBase Issue Type: Sub-task Reporter: Ted Yu Fix For: 0.96.0 The read/write load pattern would be different across region server groups. It is desirable for each group to have unique configuration parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
