[jira] [Commented] (HBASE-7634) Replication handling of changes to peer clusters is inefficient
[ https://issues.apache.org/jira/browse/HBASE-7634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722190#comment-13722190 ] Gabriel Reid commented on HBASE-7634: - Yes, will rebase this in the course of the next couple of days -- sorry for the delay on this. Replication handling of changes to peer clusters is inefficient --- Key: HBASE-7634 URL: https://issues.apache.org/jira/browse/HBASE-7634 Project: HBase Issue Type: Bug Components: Replication Affects Versions: 0.95.2 Reporter: Gabriel Reid Attachments: HBASE-7634.patch, HBASE-7634.v2.patch, HBASE-7634.v3.patch The current handling of changes to the region servers in a replication peer cluster is currently quite inefficient. The list of region servers that are being replicated to is only updated if there are a large number of issues encountered while replicating. This can cause it to take quite a while to recognize that a number of the regionserver in a peer cluster are no longer available. A potentially bigger problem is that if a replication peer cluster is started with a small number of regionservers, and then more region servers are added after replication has started, the additional region servers will never be used for replication (unless there are failures on the in-use regionservers). Part of the current issue is that the retry code in ReplicationSource#shipEdits checks a randomly-chosen replication peer regionserver (in ReplicationSource#isSlaveDown) to see if it is up after a replication write has failed on a different randonly-chosen replication peer. If the peer is seen as not down, another randomly-chosen peer is used for writing. A second part of the issue is that changes to the list of region servers in a peer cluster are not detected at all, and are only picked up if a certain number of failures have occurred when trying to ship edits. -- 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-8874) PutCombiner is skipping KeyValues while combining puts of same row during bulkload
[
https://issues.apache.org/jira/browse/HBASE-8874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajeshbabu updated HBASE-8874:
--
Attachment: HBASE-8874_trunk_3.patch
Patch addressing chunhui's comments.
Thanks Ted and chunhui for review.
PutCombiner is skipping KeyValues while combining puts of same row during
bulkload
--
Key: HBASE-8874
URL: https://issues.apache.org/jira/browse/HBASE-8874
Project: HBase
Issue Type: Bug
Components: mapreduce
Affects Versions: 0.95.0, 0.95.1
Reporter: rajeshbabu
Assignee: rajeshbabu
Priority: Critical
Fix For: 0.98.0, 0.95.2
Attachments: HBASE-8874_trunk_2.patch, HBASE-8874_trunk_3.patch,
HBASE-8874_trunk.patch
While combining puts of same row in map phase we are using below logic in
PutCombiner#reduce. In for loop first time we will add one Put object to puts
map. Next time onwards we are just overriding key values of a family with key
values of the same family in other put. So we are mostly writing one Put
object to map output and remaining will be skipped(data loss).
{code}
Mapbyte[], Put puts = new TreeMapbyte[], Put(Bytes.BYTES_COMPARATOR);
for (Put p : vals) {
cnt++;
if (!puts.containsKey(p.getRow())) {
puts.put(p.getRow(), p);
} else {
puts.get(p.getRow()).getFamilyMap().putAll(p.getFamilyMap());
}
}
{code}
We need to change logic similar as below because we are sure the rowkey of
all the puts will be same.
{code}
Put finalPut = null;
Mapbyte[], List? extends Cell familyMap = null;
for (Put p : vals) {
cnt++;
if (finalPut==null) {
finalPut = p;
familyMap = finalPut.getFamilyMap();
} else {
for (Entrybyte[], List? extends Cell entry :
p.getFamilyMap().entrySet()) {
List? extends Cell list = familyMap.get(entry.getKey());
if (list == null) {
familyMap.put(entry.getKey(), entry.getValue());
} else {
(((ListKeyValue)list)).addAll((ListKeyValue)entry.getValue());
}
}
}
}
context.write(row, finalPut);
{code}
Also need to implement TODOs mentioned by Nick
{code}
// TODO: would be better if we knew codeK row/code and Put rowkey were
// identical. Then this whole Put buffering business goes away.
// TODO: Could use HeapSize to create an upper bound on the memory size of
// the puts map and flush some portion of the content while looping. This
// flush could result in multiple Puts for a single rowkey. That is
// acceptable because Combiner is run as an optimization and it's not
// critical that all Puts are grouped perfectly.
{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-8768) Improve bulk load performance by moving key value construction from map phase to reduce phase.
[
https://issues.apache.org/jira/browse/HBASE-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajeshbabu updated HBASE-8768:
--
Status: Open (was: Patch Available)
Improve bulk load performance by moving key value construction from map phase
to reduce phase.
--
Key: HBASE-8768
URL: https://issues.apache.org/jira/browse/HBASE-8768
Project: HBase
Issue Type: Improvement
Components: mapreduce, Performance
Reporter: rajeshbabu
Assignee: rajeshbabu
Attachments: HBASE-8768_v2.patch,
HBase_Bulkload_Performance_Improvement.pdf
ImportTSV bulkloading approach uses MapReduce framework. Existing mapper and
reducer classes used by ImportTSV are TsvImporterMapper.java and
PutSortReducer.java. ImportTSV tool parses the tab(by default) seperated
values from the input files and Mapper class generates the PUT objects for
each row using the Key value pairs created from the parsed text.
PutSortReducer then uses the partions based on the regions and sorts the Put
objects for each region.
Overheads we can see in the above approach:
==
1) keyvalue construction for each parsed value in the line adding extra data
like rowkey,columnfamily,qualifier which will increase around 5x extra data
to be shuffled in reduce phase.
We can calculate data size to shuffled as below
{code}
Data to be shuffled = nl*nt*(rl+cfl+cql+vall+tsl+30)
{code}
If we move keyvalue construction to reduce phase we datasize to be shuffle
will be which is very less compared to above.
{code}
Data to be shuffled = nl*nt*vall
{code}
nl - Number of lines in the raw file
nt - Number of tabs or columns including row key.
rl - row length which will be different for each line.
cfl - column family length which will be different for each family
cql - qualifier length
tsl - timestamp length.
vall- each parsed value length.
30 bytes for kv size,number of families etc.
2) In mapper side we are creating put objects by adding all keyvalues
constructed for each line and in reducer we will again collect keyvalues from
put and sort them.
Instead we can directly create and sort keyvalues in reducer.
Solution:
We can improve bulk load performance by moving the key value construction
from mapper to reducer so that Mapper just sends the raw text for each row to
the Reducer. Reducer then parses the records for rows and create and sort the
key value pairs before writing to HFiles.
Conclusion:
===
The above suggestions will improve map phase performance by avoiding keyvalue
construction and reduce phase performance by avoiding excess data to be
shuffled.
--
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-8768) Improve bulk load performance by moving key value construction from map phase to reduce phase.
[
https://issues.apache.org/jira/browse/HBASE-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajeshbabu updated HBASE-8768:
--
Status: Patch Available (was: Open)
Improve bulk load performance by moving key value construction from map phase
to reduce phase.
--
Key: HBASE-8768
URL: https://issues.apache.org/jira/browse/HBASE-8768
Project: HBase
Issue Type: Improvement
Components: mapreduce, Performance
Reporter: rajeshbabu
Assignee: rajeshbabu
Attachments: HBASE-8768_v2.patch, HBASE-8768_v3.patch,
HBase_Bulkload_Performance_Improvement.pdf
ImportTSV bulkloading approach uses MapReduce framework. Existing mapper and
reducer classes used by ImportTSV are TsvImporterMapper.java and
PutSortReducer.java. ImportTSV tool parses the tab(by default) seperated
values from the input files and Mapper class generates the PUT objects for
each row using the Key value pairs created from the parsed text.
PutSortReducer then uses the partions based on the regions and sorts the Put
objects for each region.
Overheads we can see in the above approach:
==
1) keyvalue construction for each parsed value in the line adding extra data
like rowkey,columnfamily,qualifier which will increase around 5x extra data
to be shuffled in reduce phase.
We can calculate data size to shuffled as below
{code}
Data to be shuffled = nl*nt*(rl+cfl+cql+vall+tsl+30)
{code}
If we move keyvalue construction to reduce phase we datasize to be shuffle
will be which is very less compared to above.
{code}
Data to be shuffled = nl*nt*vall
{code}
nl - Number of lines in the raw file
nt - Number of tabs or columns including row key.
rl - row length which will be different for each line.
cfl - column family length which will be different for each family
cql - qualifier length
tsl - timestamp length.
vall- each parsed value length.
30 bytes for kv size,number of families etc.
2) In mapper side we are creating put objects by adding all keyvalues
constructed for each line and in reducer we will again collect keyvalues from
put and sort them.
Instead we can directly create and sort keyvalues in reducer.
Solution:
We can improve bulk load performance by moving the key value construction
from mapper to reducer so that Mapper just sends the raw text for each row to
the Reducer. Reducer then parses the records for rows and create and sort the
key value pairs before writing to HFiles.
Conclusion:
===
The above suggestions will improve map phase performance by avoiding keyvalue
construction and reduce phase performance by avoiding excess data to be
shuffled.
--
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-8768) Improve bulk load performance by moving key value construction from map phase to reduce phase.
[
https://issues.apache.org/jira/browse/HBASE-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajeshbabu updated HBASE-8768:
--
Attachment: HBASE-8768_v3.patch
Patch Addressing Anoop's comments.
Improve bulk load performance by moving key value construction from map phase
to reduce phase.
--
Key: HBASE-8768
URL: https://issues.apache.org/jira/browse/HBASE-8768
Project: HBase
Issue Type: Improvement
Components: mapreduce, Performance
Reporter: rajeshbabu
Assignee: rajeshbabu
Attachments: HBASE-8768_v2.patch, HBASE-8768_v3.patch,
HBase_Bulkload_Performance_Improvement.pdf
ImportTSV bulkloading approach uses MapReduce framework. Existing mapper and
reducer classes used by ImportTSV are TsvImporterMapper.java and
PutSortReducer.java. ImportTSV tool parses the tab(by default) seperated
values from the input files and Mapper class generates the PUT objects for
each row using the Key value pairs created from the parsed text.
PutSortReducer then uses the partions based on the regions and sorts the Put
objects for each region.
Overheads we can see in the above approach:
==
1) keyvalue construction for each parsed value in the line adding extra data
like rowkey,columnfamily,qualifier which will increase around 5x extra data
to be shuffled in reduce phase.
We can calculate data size to shuffled as below
{code}
Data to be shuffled = nl*nt*(rl+cfl+cql+vall+tsl+30)
{code}
If we move keyvalue construction to reduce phase we datasize to be shuffle
will be which is very less compared to above.
{code}
Data to be shuffled = nl*nt*vall
{code}
nl - Number of lines in the raw file
nt - Number of tabs or columns including row key.
rl - row length which will be different for each line.
cfl - column family length which will be different for each family
cql - qualifier length
tsl - timestamp length.
vall- each parsed value length.
30 bytes for kv size,number of families etc.
2) In mapper side we are creating put objects by adding all keyvalues
constructed for each line and in reducer we will again collect keyvalues from
put and sort them.
Instead we can directly create and sort keyvalues in reducer.
Solution:
We can improve bulk load performance by moving the key value construction
from mapper to reducer so that Mapper just sends the raw text for each row to
the Reducer. Reducer then parses the records for rows and create and sort the
key value pairs before writing to HFiles.
Conclusion:
===
The above suggestions will improve map phase performance by avoiding keyvalue
construction and reduce phase performance by avoiding excess data to be
shuffled.
--
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-6826) [WINDOWS] TestFromClientSide failures
[
https://issues.apache.org/jira/browse/HBASE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722216#comment-13722216
]
Liang Xie commented on HBASE-6826:
--
seems it's not in 0.94 yet, [~lhofhansl], would you like take it in? i observed
testClientPoolRoundRobin failure today in our 0.94.3 codebase. thanks
[WINDOWS] TestFromClientSide failures
-
Key: HBASE-6826
URL: https://issues.apache.org/jira/browse/HBASE-6826
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.3, 0.95.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Labels: windows
Fix For: 0.95.0
Attachments: hbase-6826_v1-0.94.patch, hbase-6826_v1-trunk.patch,
hbase-6826_v2-0.94.patch, hbase-6826_v2-trunk.patch
The following tests fail for TestFromClientSide:
{code}
testPoolBehavior()
testClientPoolRoundRobin()
testClientPoolThreadLocal()
{code}
The first test fails due to the fact that the test (wrongly) assumes that
ThredPoolExecutor can reclaim the thread immediately.
The second and third tests seem to fail because that Put's to the table does
not specify an explicit timestamp, but on windows, consecutive calls to put
happen to finish in the same milisecond so that the resulting mutations have
the same timestamp, thus there is only one version of the cell 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-8960) TestDistributedLogSplitting.testLogReplayForDisablingTable fails sometimes
[
https://issues.apache.org/jira/browse/HBASE-8960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Zhong updated HBASE-8960:
-
Attachment: hbase-8960-addendum.patch
1. Refactor code in order for test cases to choose RS with right regions
2. Close ZooKeeperWatcher to avoid running out of zookeeper connection.
TestDistributedLogSplitting.testLogReplayForDisablingTable fails sometimes
--
Key: HBASE-8960
URL: https://issues.apache.org/jira/browse/HBASE-8960
Project: HBase
Issue Type: Task
Components: test
Reporter: Jimmy Xiang
Assignee: Jeffrey Zhong
Priority: Minor
Fix For: 0.95.2
Attachments: hbase-8960-addendum.patch, hbase-8960.patch
http://54.241.6.143/job/HBase-0.95-Hadoop-2/org.apache.hbase$hbase-server/634/testReport/junit/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testLogReplayForDisablingTable/
{noformat}
java.lang.AssertionError: expected:1000 but was:0
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.testLogReplayForDisablingTable(TestDistributedLogSplitting.java:797)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
{noformat}
--
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-8768) Improve bulk load performance by moving key value construction from map phase to reduce phase.
[
https://issues.apache.org/jira/browse/HBASE-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajeshbabu updated HBASE-8768:
--
Fix Version/s: 0.95.2
0.98.0
Improve bulk load performance by moving key value construction from map phase
to reduce phase.
--
Key: HBASE-8768
URL: https://issues.apache.org/jira/browse/HBASE-8768
Project: HBase
Issue Type: Improvement
Components: mapreduce, Performance
Reporter: rajeshbabu
Assignee: rajeshbabu
Fix For: 0.98.0, 0.95.2
Attachments: HBASE-8768_v2.patch, HBASE-8768_v3.patch,
HBase_Bulkload_Performance_Improvement.pdf
ImportTSV bulkloading approach uses MapReduce framework. Existing mapper and
reducer classes used by ImportTSV are TsvImporterMapper.java and
PutSortReducer.java. ImportTSV tool parses the tab(by default) seperated
values from the input files and Mapper class generates the PUT objects for
each row using the Key value pairs created from the parsed text.
PutSortReducer then uses the partions based on the regions and sorts the Put
objects for each region.
Overheads we can see in the above approach:
==
1) keyvalue construction for each parsed value in the line adding extra data
like rowkey,columnfamily,qualifier which will increase around 5x extra data
to be shuffled in reduce phase.
We can calculate data size to shuffled as below
{code}
Data to be shuffled = nl*nt*(rl+cfl+cql+vall+tsl+30)
{code}
If we move keyvalue construction to reduce phase we datasize to be shuffle
will be which is very less compared to above.
{code}
Data to be shuffled = nl*nt*vall
{code}
nl - Number of lines in the raw file
nt - Number of tabs or columns including row key.
rl - row length which will be different for each line.
cfl - column family length which will be different for each family
cql - qualifier length
tsl - timestamp length.
vall- each parsed value length.
30 bytes for kv size,number of families etc.
2) In mapper side we are creating put objects by adding all keyvalues
constructed for each line and in reducer we will again collect keyvalues from
put and sort them.
Instead we can directly create and sort keyvalues in reducer.
Solution:
We can improve bulk load performance by moving the key value construction
from mapper to reducer so that Mapper just sends the raw text for each row to
the Reducer. Reducer then parses the records for rows and create and sort the
key value pairs before writing to HFiles.
Conclusion:
===
The above suggestions will improve map phase performance by avoiding keyvalue
construction and reduce phase performance by avoiding excess data to be
shuffled.
--
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-8960) TestDistributedLogSplitting.testLogReplayForDisablingTable fails sometimes
[
https://issues.apache.org/jira/browse/HBASE-8960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722254#comment-13722254
]
Hadoop QA commented on HBASE-8960:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12594639/hbase-8960-addendum.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6507//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6507//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6507//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6507//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6507//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6507//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6507//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6507//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6507//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6507//console
This message is automatically generated.
TestDistributedLogSplitting.testLogReplayForDisablingTable fails sometimes
--
Key: HBASE-8960
URL: https://issues.apache.org/jira/browse/HBASE-8960
Project: HBase
Issue Type: Task
Components: test
Reporter: Jimmy Xiang
Assignee: Jeffrey Zhong
Priority: Minor
Fix For: 0.95.2
Attachments: hbase-8960-addendum.patch, hbase-8960.patch
http://54.241.6.143/job/HBase-0.95-Hadoop-2/org.apache.hbase$hbase-server/634/testReport/junit/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testLogReplayForDisablingTable/
{noformat}
java.lang.AssertionError: expected:1000 but was:0
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.testLogReplayForDisablingTable(TestDistributedLogSplitting.java:797)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
{noformat}
--
This message is
[jira] [Commented] (HBASE-8768) Improve bulk load performance by moving key value construction from map phase to reduce phase.
[
https://issues.apache.org/jira/browse/HBASE-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722257#comment-13722257
]
Hadoop QA commented on HBASE-8768:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12594638/HBASE-8768_v3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 6 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 1
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6508//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6508//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6508//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6508//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6508//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6508//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6508//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6508//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6508//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6508//console
This message is automatically generated.
Improve bulk load performance by moving key value construction from map phase
to reduce phase.
--
Key: HBASE-8768
URL: https://issues.apache.org/jira/browse/HBASE-8768
Project: HBase
Issue Type: Improvement
Components: mapreduce, Performance
Reporter: rajeshbabu
Assignee: rajeshbabu
Fix For: 0.98.0, 0.95.2
Attachments: HBASE-8768_v2.patch, HBASE-8768_v3.patch,
HBase_Bulkload_Performance_Improvement.pdf
ImportTSV bulkloading approach uses MapReduce framework. Existing mapper and
reducer classes used by ImportTSV are TsvImporterMapper.java and
PutSortReducer.java. ImportTSV tool parses the tab(by default) seperated
values from the input files and Mapper class generates the PUT objects for
each row using the Key value pairs created from the parsed text.
PutSortReducer then uses the partions based on the regions and sorts the Put
objects for each region.
Overheads we can see in the above approach:
==
1) keyvalue construction for each parsed value in the line adding extra data
like rowkey,columnfamily,qualifier which will increase around 5x extra data
to be shuffled in reduce phase.
We can calculate data size to shuffled as below
{code}
Data to be shuffled = nl*nt*(rl+cfl+cql+vall+tsl+30)
{code}
If we move keyvalue construction to reduce phase we datasize to be shuffle
will be which is very less compared to above.
{code}
Data to be shuffled = nl*nt*vall
{code}
nl - Number of lines in the raw file
nt - Number of tabs or columns including row key.
rl - row length which will be different for each line.
cfl - column family length which will be different for each family
cql - qualifier length
tsl - timestamp length.
vall- each parsed value length.
30 bytes for kv size,number of families etc.
2) In mapper side we are creating put objects by
[jira] [Commented] (HBASE-9041) TestFlushSnapshotFromClient.testConcurrentSnapshottingAttempts fails
[ https://issues.apache.org/jira/browse/HBASE-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722260#comment-13722260 ] Matteo Bertozzi commented on HBASE-9041: no that looks like is just slow, the testConcurrentSnapshottingAttempts() has a fixed stop at 60sec. A couple of snapshots are done, the others are not. but they are not failed, so the test is waiting for completion until the 60sec timeout mark the test as failed TestFlushSnapshotFromClient.testConcurrentSnapshottingAttempts fails Key: HBASE-9041 URL: https://issues.apache.org/jira/browse/HBASE-9041 Project: HBase Issue Type: Bug Components: snapshots, test Reporter: stack Assignee: Matteo Bertozzi Priority: Critical Fix For: 0.95.2 Attachments: HBASE-9041-v0.patch, lessrows.txt, uppingrows.txt Assigning Matteo to take a look (give back to me if you don't have time boss). Failed here: https://builds.apache.org/job/HBase-TRUNK/4293/testReport/org.apache.hadoop.hbase.snapshot/TestFlushSnapshotFromClient/testConcurrentSnapshottingAttempts/ Yesterday, it failed in a different place and for different reason: https://builds.apache.org/view/H-L/view/HBase/job/hbase-0.95/352/testReport/junit/org.apache.hadoop.hbase.snapshot/TestFlushSnapshotFromClient/testFlushTableSnapshot/ The latter test fail was noted on tail of HBASE-8984. There I speculate that its the 'load' of 400. I don't think the load reporting is correct. Will dig in on that. -- 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-9042) Can't get TestHCM#testClusterStatus to work
[
https://issues.apache.org/jira/browse/HBASE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722266#comment-13722266
]
Lars Francke commented on HBASE-9042:
-
Thanks stack, sounds good to me! I don't have a better solution either. I tried
looking into it but couldn't find the cause either.
Can't get TestHCM#testClusterStatus to work
---
Key: HBASE-9042
URL: https://issues.apache.org/jira/browse/HBASE-9042
Project: HBase
Issue Type: Bug
Components: test
Reporter: Lars Francke
Priority: Minor
Attachments: HBASE-9042.1.txt
I can't get HBase trunk to build. In particular TestHCM.testClusterStatus
always fails for me. I tried on my own Jenkins as well as my IDE (IntelliJ)
with the same result (two different machines, CentOS Mac OS).
mvn -U -PrunAllTests -Dmaven.test.redirectTestOutputToFile=true
-Dit.test=noItTest clean install
I've attached the full log. It fails on the last wait by exceeding the
timeout. This is reported:
{code}
- Thread LEAK? -, OpenFileDescriptor=417 (was 440), MaxFileDescriptor=4096
(was 4096), SystemLoadAverage=227 (was 265), ProcessCount=243 (was 240) -
ProcessCount LEAK? -, AvailableMemoryMB=2196 (was 1991) - AvailableMemoryMB
LEAK? -, ConnectionCount=7 (was 6) - ConnectionCount LEAK? -
{code}
And the Thread dump (see attached file) has a bunch of things reported as
potentially hanging threads.
From my MacBook's command line I got the test to pass using the same
command but not in Jenkins or from IntelliJ.
--
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-8874) PutCombiner is skipping KeyValues while combining puts of same row during bulkload
[
https://issues.apache.org/jira/browse/HBASE-8874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722289#comment-13722289
]
Hadoop QA commented on HBASE-8874:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12594637/HBASE-8874_trunk_3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6509//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6509//console
This message is automatically generated.
PutCombiner is skipping KeyValues while combining puts of same row during
bulkload
--
Key: HBASE-8874
URL: https://issues.apache.org/jira/browse/HBASE-8874
Project: HBase
Issue Type: Bug
Components: mapreduce
Affects Versions: 0.95.0, 0.95.1
Reporter: rajeshbabu
Assignee: rajeshbabu
Priority: Critical
Fix For: 0.98.0, 0.95.2
Attachments: HBASE-8874_trunk_2.patch, HBASE-8874_trunk_3.patch,
HBASE-8874_trunk.patch
While combining puts of same row in map phase we are using below logic in
PutCombiner#reduce. In for loop first time we will add one Put object to puts
map. Next time onwards we are just overriding key values of a family with key
values of the same family in other put. So we are mostly writing one Put
object to map output and remaining will be skipped(data loss).
{code}
Mapbyte[], Put puts = new TreeMapbyte[], Put(Bytes.BYTES_COMPARATOR);
for (Put p : vals) {
cnt++;
if (!puts.containsKey(p.getRow())) {
puts.put(p.getRow(), p);
} else {
puts.get(p.getRow()).getFamilyMap().putAll(p.getFamilyMap());
}
}
{code}
We need to change logic similar as below because we are sure the rowkey of
all the puts will be same.
{code}
Put finalPut = null;
Mapbyte[], List? extends Cell familyMap = null;
for (Put p : vals) {
cnt++;
if (finalPut==null) {
finalPut = p;
familyMap = finalPut.getFamilyMap();
} else {
for (Entrybyte[], List? extends Cell entry :
p.getFamilyMap().entrySet()) {
List? extends Cell list = familyMap.get(entry.getKey());
if (list == null) {
[jira] [Updated] (HBASE-9071) Disable TestHCM#testClusterStatus because fails in IDEs, etc.
[ https://issues.apache.org/jira/browse/HBASE-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-9071: - Attachment: 9071.txt Disable TestHCM#testClusterStatus because fails in IDEs, etc. - Key: HBASE-9071 URL: https://issues.apache.org/jira/browse/HBASE-9071 Project: HBase Issue Type: Sub-task Components: test Reporter: stack Fix For: 0.95.2 Attachments: 9071.txt Disabling for now until someone has time to take a look. -- 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-9071) Disable TestHCM#testClusterStatus because fails in IDEs, etc.
stack created HBASE-9071: Summary: Disable TestHCM#testClusterStatus because fails in IDEs, etc. Key: HBASE-9071 URL: https://issues.apache.org/jira/browse/HBASE-9071 Project: HBase Issue Type: Sub-task Components: test Reporter: stack Fix For: 0.95.2 Attachments: 9071.txt Disabling for now until someone has time to take a look. -- 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-9042) Can't get TestHCM#testClusterStatus to work
[
https://issues.apache.org/jira/browse/HBASE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722532#comment-13722532
]
stack commented on HBASE-9042:
--
[~lars_francke] I disabled it via sub-issue for now.
Can't get TestHCM#testClusterStatus to work
---
Key: HBASE-9042
URL: https://issues.apache.org/jira/browse/HBASE-9042
Project: HBase
Issue Type: Bug
Components: test
Reporter: Lars Francke
Priority: Minor
Attachments: HBASE-9042.1.txt
I can't get HBase trunk to build. In particular TestHCM.testClusterStatus
always fails for me. I tried on my own Jenkins as well as my IDE (IntelliJ)
with the same result (two different machines, CentOS Mac OS).
mvn -U -PrunAllTests -Dmaven.test.redirectTestOutputToFile=true
-Dit.test=noItTest clean install
I've attached the full log. It fails on the last wait by exceeding the
timeout. This is reported:
{code}
- Thread LEAK? -, OpenFileDescriptor=417 (was 440), MaxFileDescriptor=4096
(was 4096), SystemLoadAverage=227 (was 265), ProcessCount=243 (was 240) -
ProcessCount LEAK? -, AvailableMemoryMB=2196 (was 1991) - AvailableMemoryMB
LEAK? -, ConnectionCount=7 (was 6) - ConnectionCount LEAK? -
{code}
And the Thread dump (see attached file) has a bunch of things reported as
potentially hanging threads.
From my MacBook's command line I got the test to pass using the same
command but not in Jenkins or from IntelliJ.
--
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] [Resolved] (HBASE-9071) Disable TestHCM#testClusterStatus because fails in IDEs, etc.
[ https://issues.apache.org/jira/browse/HBASE-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-9071. -- Resolution: Fixed Assignee: stack Committed to trunk and 0.95. Disable TestHCM#testClusterStatus because fails in IDEs, etc. - Key: HBASE-9071 URL: https://issues.apache.org/jira/browse/HBASE-9071 Project: HBase Issue Type: Sub-task Components: test Reporter: stack Assignee: stack Fix For: 0.95.2 Attachments: 9071.txt Disabling for now until someone has time to take a look. -- 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-9041) TestFlushSnapshotFromClient.testConcurrentSnapshottingAttempts fails
[ https://issues.apache.org/jira/browse/HBASE-9041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722533#comment-13722533 ] stack commented on HBASE-9041: -- [~mbertozzi] Sounds like I should up 60s timeouts to 5minutes all over the code base? TestFlushSnapshotFromClient.testConcurrentSnapshottingAttempts fails Key: HBASE-9041 URL: https://issues.apache.org/jira/browse/HBASE-9041 Project: HBase Issue Type: Bug Components: snapshots, test Reporter: stack Assignee: Matteo Bertozzi Priority: Critical Fix For: 0.95.2 Attachments: HBASE-9041-v0.patch, lessrows.txt, uppingrows.txt Assigning Matteo to take a look (give back to me if you don't have time boss). Failed here: https://builds.apache.org/job/HBase-TRUNK/4293/testReport/org.apache.hadoop.hbase.snapshot/TestFlushSnapshotFromClient/testConcurrentSnapshottingAttempts/ Yesterday, it failed in a different place and for different reason: https://builds.apache.org/view/H-L/view/HBase/job/hbase-0.95/352/testReport/junit/org.apache.hadoop.hbase.snapshot/TestFlushSnapshotFromClient/testFlushTableSnapshot/ The latter test fail was noted on tail of HBASE-8984. There I speculate that its the 'load' of 400. I don't think the load reporting is correct. Will dig in on that. -- 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-8960) TestDistributedLogSplitting.testLogReplayForDisablingTable fails sometimes
[
https://issues.apache.org/jira/browse/HBASE-8960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722534#comment-13722534
]
stack commented on HBASE-8960:
--
+1 on commit. Nice clean up of a bunch of duplicated code. Thanks [~jeffreyz]
TestDistributedLogSplitting.testLogReplayForDisablingTable fails sometimes
--
Key: HBASE-8960
URL: https://issues.apache.org/jira/browse/HBASE-8960
Project: HBase
Issue Type: Task
Components: test
Reporter: Jimmy Xiang
Assignee: Jeffrey Zhong
Priority: Minor
Fix For: 0.95.2
Attachments: hbase-8960-addendum.patch, hbase-8960.patch
http://54.241.6.143/job/HBase-0.95-Hadoop-2/org.apache.hbase$hbase-server/634/testReport/junit/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testLogReplayForDisablingTable/
{noformat}
java.lang.AssertionError: expected:1000 but was:0
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.hadoop.hbase.master.TestDistributedLogSplitting.testLogReplayForDisablingTable(TestDistributedLogSplitting.java:797)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
{noformat}
--
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-9012) TestBlockReorder.testBlockLocationReorder fails
[ https://issues.apache.org/jira/browse/HBASE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722539#comment-13722539 ] stack commented on HBASE-9012: -- It failed this morning: http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/427/testReport/org.apache.hadoop.hbase.fs/TestBlockReorder/testBlockLocationReorder/ Looks like we tried to bind ten times and each time we failed: 2013-07-29 09:18:28,414 INFO [pool-1-thread-1] fs.TestBlockReorder(191): Got bind exception trying to set up socket on 53699; waiting a while; retry=0 2013-07-29 09:18:29,416 INFO [pool-1-thread-1] fs.TestBlockReorder(191): Got bind exception trying to set up socket on 53699; waiting a while; retry=1 2013-07-29 09:18:30,416 INFO [pool-1-thread-1] fs.TestBlockReorder(191): Got bind exception trying to set up socket on 53699; waiting a while; retry=2 2013-07-29 09:18:31,417 INFO [pool-1-thread-1] fs.TestBlockReorder(191): Got bind exception trying to set up socket on 53699; waiting a while; retry=3 2013-07-29 09:18:32,418 INFO [pool-1-thread-1] fs.TestBlockReorder(191): Got bind exception trying to set up socket on 53699; waiting a while; retry=4 2013-07-29 09:18:33,419 INFO [pool-1-thread-1] fs.TestBlockReorder(191): Got bind exception trying to set up socket on 53699; waiting a while; retry=5 2013-07-29 09:18:34,419 INFO [pool-1-thread-1] fs.TestBlockReorder(191): Got bind exception trying to set up socket on 53699; waiting a while; retry=6 2013-07-29 09:18:35,420 INFO [pool-1-thread-1] fs.TestBlockReorder(191): Got bind exception trying to set up socket on 53699; waiting a while; retry=7 2013-07-29 09:18:36,421 INFO [pool-1-thread-1] fs.TestBlockReorder(191): Got bind exception trying to set up socket on 53699; waiting a while; retry=8 2013-07-29 09:18:37,422 INFO [pool-1-thread-1] fs.TestBlockReorder(191): Got bind exception trying to set up socket on 53699; waiting a while; retry=9 I could have us retry until we get a good port? TestBlockReorder.testBlockLocationReorder fails --- Key: HBASE-9012 URL: https://issues.apache.org/jira/browse/HBASE-9012 Project: HBase Issue Type: Bug Components: test Reporter: stack Assignee: stack Fix For: 0.95.2 Attachments: 9012.txt http://54.241.6.143/job/HBase-0.95/669/org.apache.hbase$hbase-server/testReport/junit/org.apache.hadoop.hbase.fs/TestBlockReorder/testBlockLocationReorder/ java.net.BindException: Address already in use at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) at java.net.ServerSocket.bind(ServerSocket.java:328) at java.net.ServerSocket.init(ServerSocket.java:194) at java.net.ServerSocket.init(ServerSocket.java:106) at org.apache.hadoop.hbase.fs.TestBlockReorder.testBlockLocationReorder(TestBlockReorder.java:182) -- 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-8803) region_mover.rb should move multiple regions at a time
[
https://issues.apache.org/jira/browse/HBASE-8803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722546#comment-13722546
]
Jean-Marc Spaggiari commented on HBASE-8803:
Hi Nick,
Can you add the thread trace in the unload log and retry? I tried again on my
side and it's still correct.
Also, I verified that regions are moved only once:
{code}
hbase@node3:~/hbase-0.94$ cat logs/hbase-hbase-master-node3.log | grep
dd86a04810f2839ee7842733b7a6ec78
2013-07-29 07:59:33,238 INFO org.apache.hadoop.hbase.master.HMaster: Added move
plan
hri=crc,\x00\x00\x00\x00+\xB1\x108seattle.cbsradio.stats.com,1365475884535.dd86a04810f2839ee7842733b7a6ec78.,
src=node3,60020,1375017424052, dest=node6,60020,1375016625878, running balancer
2013-07-29 08:01:40,131 INFO org.apache.hadoop.hbase.master.HMaster: Added move
plan
hricrc,\x00\x00\x00\x00+\xB1\x108seattle.cbsradio.stats.com,1365475884535.dd86a04810f2839ee7842733b7a6ec78.,
src=node6,60020,1375016625878, dest=node3,60020,1375099217169, running balancer
{code}
Let me know if you need an updated patch for the unload output. What you should
see is something like that:
{code}
Gracefully restarting: node1
Doing rolling with maxthreads=30
Disabling balancer! (if required)
Previous balancer state was true
Unloading node1 region(s)
Valid region move targets:
node4,60020,1375016907951
buldo,60020,1375016770574
node5,60020,1375017021737
node7,60020,1375017151389
node2,60020,1375015919731
node3,60020,1375015482026
node6,60020,1375016625878
13/07/28 09:13:31 INFO region_mover: Moving 88 region(s) from
node1,60020,1375015859230 during this cycle
13/07/28 09:13:31 INFO region_mover: Moving region
0543a51c262cf78561e4d2d07867385b (1 of 88) to server=node4,60020,1375016907951
in thread 0
13/07/28 09:13:31 INFO region_mover: Moving region
86fe96d85203f15ec769a1ab84ea652e (2 of 88) to server=buldo,60020,1375016770574
in thread 1
13/07/28 09:13:31 INFO region_mover: Moving region
323b9de45db8b4bc8b200a33550bf339 (3 of 88) to server=node5,60020,1375017021737
in thread 2
13/07/28 09:13:31 INFO region_mover: Moving region
796665161dc582ac0beb37fdcdd82db8 (4 of 88) to server=node7,60020,1375017151389
in thread 3
13/07/28 09:13:31 INFO region_mover: Moving region
a5d61d600d21fb05253e8afa2489d7ef (5 of 88) to server=node2,60020,1375015919731
in thread 4
13/07/28 09:13:31 INFO region_mover: Moving region
3d326f914d8c3eb40db8d48e945bd618 (6 of 88) to server=node3,60020,1375015482026
in thread 5
13/07/28 09:13:31 INFO region_mover: Moving region
1c65891f0a76bc26b45364cf2311841e (7 of 88) to server=node6,60020,1375016625878
in thread 6
13/07/28 09:13:32 INFO region_mover: Moving region
bd4bbdcc078742d0d9474bcfc91cbb3b (8 of 88) to server=node4,60020,1375016907951
in thread 0
13/07/28 09:13:32 INFO region_mover: Moving region
5613e945414d1be0e0eaff89891554f1 (9 of 88) to server=buldo,60020,1375016770574
in thread 1
13/07/28 09:13:32 INFO region_mover: Moving region
fe44b401dfe7e4924601ef909032ad28 (10 of 88) to server=node5,60020,1375017021737
in thread 2
13/07/28 09:13:32 INFO region_mover: Moving region
0d4762ae7f855f3ff14abdf4c7e1acec (11 of 88) to server=node7,60020,1375017151389
in thread 3
13/07/28 09:13:32 INFO region_mover: Moving region
86e0f44b1ca082fada429ed2ee798806 (12 of 88) to server=node2,60020,1375015919731
in thread 4
13/07/28 09:13:32 INFO region_mover: Moving region
8d295e0ceb2bd62952d9e47dd81699c6 (13 of 88) to server=node3,60020,1375015482026
in thread 5
13/07/28 09:13:32 INFO region_mover: Moving region
ae0b4649917574b82f7d8f2779800cd0 (14 of 88) to server=node6,60020,1375016625878
in thread 6
13/07/28 09:13:34 INFO region_mover: Moving region
73a6401006f8e7e1a7c2d5e7d9e4436d (15 of 88) to server=node4,60020,1375016907951
in thread 0
13/07/28 09:13:34 INFO region_mover: Moving region
8beeb42f41b04aa38c020e2173e4ed5e (16 of 88) to server=buldo,60020,1375016770574
in thread 1
13/07/28 09:13:34 INFO region_mover: Moving region
47ef6f201b2b96558dafd50f6062c1f3 (17 of 88) to server=node5,60020,1375017021737
in thread 2
13/07/28 09:13:34 INFO region_mover: Moving region
4c6e30b8d0d320be240d4edeffbfff17 (18 of 88) to server=node7,60020,1375017151389
in thread 3
13/07/28 09:13:34 INFO region_mover: Moving region
09d98ca982d2c36f616ec568deafc954 (19 of 88) to server=node2,60020,1375015919731
in thread 4
13/07/28 09:13:34 INFO region_mover: Moving region
39bcc1fc090c8a939dca5b45e2119122 (20 of 88) to server=node3,60020,1375015482026
in thread 5
13/07/28 09:13:34 INFO region_mover: Moving region
3ded89d9383bdd518a5d24d7c478ed50 (21 of 88) to server=node6,60020,1375016625878
in thread 6
13/07/28 09:13:36 INFO region_mover: Moving region
05a6717f7a01222017c5328cc6cf3401 (22 of 88) to server=node4,60020,1375016907951
in thread 0
13/07/28 09:13:36 INFO region_mover: Moving region
08cfbeed57512350323e9172b28157b2 (23 of 88) to
[jira] [Updated] (HBASE-8874) PutCombiner is skipping KeyValues while combining puts of same row during bulkload
[
https://issues.apache.org/jira/browse/HBASE-8874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-8874:
--
Hadoop Flags: Reviewed
Integrated to 0.95 and trunk.
Thanks for the patch, Rajeshbabu.
Thanks for the reviews.
PutCombiner is skipping KeyValues while combining puts of same row during
bulkload
--
Key: HBASE-8874
URL: https://issues.apache.org/jira/browse/HBASE-8874
Project: HBase
Issue Type: Bug
Components: mapreduce
Affects Versions: 0.95.0, 0.95.1
Reporter: rajeshbabu
Assignee: rajeshbabu
Priority: Critical
Fix For: 0.98.0, 0.95.2
Attachments: HBASE-8874_trunk_2.patch, HBASE-8874_trunk_3.patch,
HBASE-8874_trunk.patch
While combining puts of same row in map phase we are using below logic in
PutCombiner#reduce. In for loop first time we will add one Put object to puts
map. Next time onwards we are just overriding key values of a family with key
values of the same family in other put. So we are mostly writing one Put
object to map output and remaining will be skipped(data loss).
{code}
Mapbyte[], Put puts = new TreeMapbyte[], Put(Bytes.BYTES_COMPARATOR);
for (Put p : vals) {
cnt++;
if (!puts.containsKey(p.getRow())) {
puts.put(p.getRow(), p);
} else {
puts.get(p.getRow()).getFamilyMap().putAll(p.getFamilyMap());
}
}
{code}
We need to change logic similar as below because we are sure the rowkey of
all the puts will be same.
{code}
Put finalPut = null;
Mapbyte[], List? extends Cell familyMap = null;
for (Put p : vals) {
cnt++;
if (finalPut==null) {
finalPut = p;
familyMap = finalPut.getFamilyMap();
} else {
for (Entrybyte[], List? extends Cell entry :
p.getFamilyMap().entrySet()) {
List? extends Cell list = familyMap.get(entry.getKey());
if (list == null) {
familyMap.put(entry.getKey(), entry.getValue());
} else {
(((ListKeyValue)list)).addAll((ListKeyValue)entry.getValue());
}
}
}
}
context.write(row, finalPut);
{code}
Also need to implement TODOs mentioned by Nick
{code}
// TODO: would be better if we knew codeK row/code and Put rowkey were
// identical. Then this whole Put buffering business goes away.
// TODO: Could use HeapSize to create an upper bound on the memory size of
// the puts map and flush some portion of the content while looping. This
// flush could result in multiple Puts for a single rowkey. That is
// acceptable because Combiner is run as an optimization and it's not
// critical that all Puts are grouped perfectly.
{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-8874) PutCombiner is skipping KeyValues while combining puts of same row during bulkload
[
https://issues.apache.org/jira/browse/HBASE-8874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
rajeshbabu updated HBASE-8874:
--
Resolution: Fixed
Status: Resolved (was: Patch Available)
PutCombiner is skipping KeyValues while combining puts of same row during
bulkload
--
Key: HBASE-8874
URL: https://issues.apache.org/jira/browse/HBASE-8874
Project: HBase
Issue Type: Bug
Components: mapreduce
Affects Versions: 0.95.0, 0.95.1
Reporter: rajeshbabu
Assignee: rajeshbabu
Priority: Critical
Fix For: 0.98.0, 0.95.2
Attachments: HBASE-8874_trunk_2.patch, HBASE-8874_trunk_3.patch,
HBASE-8874_trunk.patch
While combining puts of same row in map phase we are using below logic in
PutCombiner#reduce. In for loop first time we will add one Put object to puts
map. Next time onwards we are just overriding key values of a family with key
values of the same family in other put. So we are mostly writing one Put
object to map output and remaining will be skipped(data loss).
{code}
Mapbyte[], Put puts = new TreeMapbyte[], Put(Bytes.BYTES_COMPARATOR);
for (Put p : vals) {
cnt++;
if (!puts.containsKey(p.getRow())) {
puts.put(p.getRow(), p);
} else {
puts.get(p.getRow()).getFamilyMap().putAll(p.getFamilyMap());
}
}
{code}
We need to change logic similar as below because we are sure the rowkey of
all the puts will be same.
{code}
Put finalPut = null;
Mapbyte[], List? extends Cell familyMap = null;
for (Put p : vals) {
cnt++;
if (finalPut==null) {
finalPut = p;
familyMap = finalPut.getFamilyMap();
} else {
for (Entrybyte[], List? extends Cell entry :
p.getFamilyMap().entrySet()) {
List? extends Cell list = familyMap.get(entry.getKey());
if (list == null) {
familyMap.put(entry.getKey(), entry.getValue());
} else {
(((ListKeyValue)list)).addAll((ListKeyValue)entry.getValue());
}
}
}
}
context.write(row, finalPut);
{code}
Also need to implement TODOs mentioned by Nick
{code}
// TODO: would be better if we knew codeK row/code and Put rowkey were
// identical. Then this whole Put buffering business goes away.
// TODO: Could use HeapSize to create an upper bound on the memory size of
// the puts map and flush some portion of the content while looping. This
// flush could result in multiple Puts for a single rowkey. That is
// acceptable because Combiner is run as an optimization and it's not
// critical that all Puts are grouped perfectly.
{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-9058) deleteSnapshot() call may be skipped in TestFlushSnapshotFromClient tests
[ https://issues.apache.org/jira/browse/HBASE-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-9058: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) deleteSnapshot() call may be skipped in TestFlushSnapshotFromClient tests - Key: HBASE-9058 URL: https://issues.apache.org/jira/browse/HBASE-9058 Project: HBase Issue Type: Test Reporter: Ted Yu Assignee: Ted Yu Priority: Minor Attachments: 9058.patch, 9058.patch, 9058-v2.patch At the end of each test, we have this call: admin.deleteSnapshot(snapshotName); However it is not placed in finally block. When assertion in earlier part of the test fails (See [1]), snapshot cleanup would be skipped, leading to SnapshotTestingUtils.assertNoSnapshots() failing for subsequent tests. [1]: https://builds.apache.org/job/hbase-0.95-on-hadoop2/197/testReport/org.apache.hadoop.hbase.snapshot/TestFlushSnapshotFromClient/testFlushCreateListDestroy/ -- 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-6826) [WINDOWS] TestFromClientSide failures
[
https://issues.apache.org/jira/browse/HBASE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722655#comment-13722655
]
Lars Hofhansl commented on HBASE-6826:
--
Test only change. Looks good.
I'll commit this to 0.94 as well.
[WINDOWS] TestFromClientSide failures
-
Key: HBASE-6826
URL: https://issues.apache.org/jira/browse/HBASE-6826
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.3, 0.95.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Labels: windows
Fix For: 0.95.0
Attachments: hbase-6826_v1-0.94.patch, hbase-6826_v1-trunk.patch,
hbase-6826_v2-0.94.patch, hbase-6826_v2-trunk.patch
The following tests fail for TestFromClientSide:
{code}
testPoolBehavior()
testClientPoolRoundRobin()
testClientPoolThreadLocal()
{code}
The first test fails due to the fact that the test (wrongly) assumes that
ThredPoolExecutor can reclaim the thread immediately.
The second and third tests seem to fail because that Put's to the table does
not specify an explicit timestamp, but on windows, consecutive calls to put
happen to finish in the same milisecond so that the resulting mutations have
the same timestamp, thus there is only one version of the cell 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-6826) [WINDOWS] TestFromClientSide failures
[
https://issues.apache.org/jira/browse/HBASE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-6826:
-
Fix Version/s: 0.94.11
0.98.0
[WINDOWS] TestFromClientSide failures
-
Key: HBASE-6826
URL: https://issues.apache.org/jira/browse/HBASE-6826
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.3, 0.95.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Labels: windows
Fix For: 0.98.0, 0.95.0, 0.94.11
Attachments: hbase-6826_v1-0.94.patch, hbase-6826_v1-trunk.patch,
hbase-6826_v2-0.94.patch, hbase-6826_v2-trunk.patch
The following tests fail for TestFromClientSide:
{code}
testPoolBehavior()
testClientPoolRoundRobin()
testClientPoolThreadLocal()
{code}
The first test fails due to the fact that the test (wrongly) assumes that
ThredPoolExecutor can reclaim the thread immediately.
The second and third tests seem to fail because that Put's to the table does
not specify an explicit timestamp, but on windows, consecutive calls to put
happen to finish in the same milisecond so that the resulting mutations have
the same timestamp, thus there is only one version of the cell 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-6826) [WINDOWS] TestFromClientSide failures
[
https://issues.apache.org/jira/browse/HBASE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-6826:
-
Fix Version/s: (was: 0.98.0)
[WINDOWS] TestFromClientSide failures
-
Key: HBASE-6826
URL: https://issues.apache.org/jira/browse/HBASE-6826
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.3, 0.95.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Labels: windows
Fix For: 0.95.0, 0.94.11
Attachments: hbase-6826_v1-0.94.patch, hbase-6826_v1-trunk.patch,
hbase-6826_v2-0.94.patch, hbase-6826_v2-trunk.patch
The following tests fail for TestFromClientSide:
{code}
testPoolBehavior()
testClientPoolRoundRobin()
testClientPoolThreadLocal()
{code}
The first test fails due to the fact that the test (wrongly) assumes that
ThredPoolExecutor can reclaim the thread immediately.
The second and third tests seem to fail because that Put's to the table does
not specify an explicit timestamp, but on windows, consecutive calls to put
happen to finish in the same milisecond so that the resulting mutations have
the same timestamp, thus there is only one version of the cell 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-9072) TestSnapshotFromMaster.testSnapshotHFileArchiving fails
stack created HBASE-9072:
Summary: TestSnapshotFromMaster.testSnapshotHFileArchiving fails
Key: HBASE-9072
URL: https://issues.apache.org/jira/browse/HBASE-9072
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/428/testReport/junit/org.apache.hadoop.hbase.master.cleaner/TestSnapshotFromMaster/testSnapshotHFileArchiving/
{code}
Failed 4600 actions: SocketTimeoutException: 4600 times,
Stacktrace
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed
4600 actions: SocketTimeoutException: 4600 times,
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:157)
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$500(AsyncProcess.java:145)
at
org.apache.hadoop.hbase.client.AsyncProcess.getErrors(AsyncProcess.java:700)
at
org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:827)
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{code}
[~mbertozzi] Opinion?
--
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-9072) TestSnapshotFromMaster.testSnapshotHFileArchiving fails
[
https://issues.apache.org/jira/browse/HBASE-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722667#comment-13722667
]
Matteo Bertozzi commented on HBASE-9072:
This is a put failing on a newly created table, no snapshot, clone or other
fancy stuff
{code}
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
{code}
are the jenkins machines too busy/too many parallel tasks?
TestSnapshotFromMaster.testSnapshotHFileArchiving fails
---
Key: HBASE-9072
URL: https://issues.apache.org/jira/browse/HBASE-9072
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/428/testReport/junit/org.apache.hadoop.hbase.master.cleaner/TestSnapshotFromMaster/testSnapshotHFileArchiving/
{code}
Failed 4600 actions: SocketTimeoutException: 4600 times,
Stacktrace
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed
4600 actions: SocketTimeoutException: 4600 times,
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:157)
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$500(AsyncProcess.java:145)
at
org.apache.hadoop.hbase.client.AsyncProcess.getErrors(AsyncProcess.java:700)
at
org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:827)
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at
[jira] [Updated] (HBASE-9063) TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState fails
[
https://issues.apache.org/jira/browse/HBASE-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-9063:
---
Attachment: trunk-9063.patch
TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState
fails
Key: HBASE-9063
URL: https://issues.apache.org/jira/browse/HBASE-9063
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
Assignee: Jimmy Xiang
Attachments: trunk-9063.patch
https://builds.apache.org/job/hbase-0.95-on-hadoop2/200/testReport/org.apache.hadoop.hbase.master/TestAssignmentManagerOnCluster/testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState/
{code}java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.AssignmentManager.regionOnline(AssignmentManager.java:1314)
at
org.apache.hadoop.hbase.master.TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState(TestAssignmentManagerOnCluster.java:482)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74){code}
Hope you don't mind my assigning it to you Jimmy. Thought you might be
interested.
--
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-9072) TestSnapshotFromMaster.testSnapshotHFileArchiving fails
[
https://issues.apache.org/jira/browse/HBASE-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-9072:
---
Description:
http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/428/testReport/junit/org.apache.hadoop.hbase.master.cleaner/TestSnapshotFromMaster/testSnapshotHFileArchiving/
{code}
Failed 4600 actions: SocketTimeoutException: 4600 times,
Stacktrace
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed
4600 actions: SocketTimeoutException: 4600 times,
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:157)
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$500(AsyncProcess.java:145)
at
org.apache.hadoop.hbase.client.AsyncProcess.getErrors(AsyncProcess.java:700)
at
org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:827)
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{code}
[~mbertozzi] Opinion?
was:
http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/428/testReport/junit/org.apache.hadoop.hbase.master.cleaner/TestSnapshotFromMaster/testSnapshotHFileArchiving/
{code}
Failed 4600 actions: SocketTimeoutException: 4600 times,
Stacktrace
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed
4600 actions: SocketTimeoutException: 4600 times,
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:157)
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$500(AsyncProcess.java:145)
at
org.apache.hadoop.hbase.client.AsyncProcess.getErrors(AsyncProcess.java:700)
at
org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:827)
at
[jira] [Commented] (HBASE-9072) TestSnapshotFromMaster.testSnapshotHFileArchiving fails
[
https://issues.apache.org/jira/browse/HBASE-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722672#comment-13722672
]
Matteo Bertozzi commented on HBASE-9072:
btw the client retries number for this test is set to 1.
TestSnapshotFromMaster.testSnapshotHFileArchiving fails
---
Key: HBASE-9072
URL: https://issues.apache.org/jira/browse/HBASE-9072
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/428/testReport/junit/org.apache.hadoop.hbase.master.cleaner/TestSnapshotFromMaster/testSnapshotHFileArchiving/
{code}
Failed 4600 actions: SocketTimeoutException: 4600 times,
Stacktrace
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed
4600 actions: SocketTimeoutException: 4600 times,
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:157)
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$500(AsyncProcess.java:145)
at
org.apache.hadoop.hbase.client.AsyncProcess.getErrors(AsyncProcess.java:700)
at
org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:827)
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{code}
[~mbertozzi] Opinion?
--
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-6826) [WINDOWS] TestFromClientSide failures
[
https://issues.apache.org/jira/browse/HBASE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722669#comment-13722669
]
Lars Hofhansl commented on HBASE-6826:
--
I ran TestFromClientSide locally, all good.
[WINDOWS] TestFromClientSide failures
-
Key: HBASE-6826
URL: https://issues.apache.org/jira/browse/HBASE-6826
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.3, 0.95.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Labels: windows
Fix For: 0.95.0, 0.94.11
Attachments: hbase-6826_v1-0.94.patch, hbase-6826_v1-trunk.patch,
hbase-6826_v2-0.94.patch, hbase-6826_v2-trunk.patch
The following tests fail for TestFromClientSide:
{code}
testPoolBehavior()
testClientPoolRoundRobin()
testClientPoolThreadLocal()
{code}
The first test fails due to the fact that the test (wrongly) assumes that
ThredPoolExecutor can reclaim the thread immediately.
The second and third tests seem to fail because that Put's to the table does
not specify an explicit timestamp, but on windows, consecutive calls to put
happen to finish in the same milisecond so that the resulting mutations have
the same timestamp, thus there is only one version of the cell 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-9063) TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState fails
[
https://issues.apache.org/jira/browse/HBASE-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-9063:
---
Status: Patch Available (was: Open)
This test failed to get a region of the newly created test table in time.
Attached a patch which increased the timeout time to get a region. Also added
some checking so that we can get some proper message in the log instead of NPE.
TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState
fails
Key: HBASE-9063
URL: https://issues.apache.org/jira/browse/HBASE-9063
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
Assignee: Jimmy Xiang
Attachments: trunk-9063.patch
https://builds.apache.org/job/hbase-0.95-on-hadoop2/200/testReport/org.apache.hadoop.hbase.master/TestAssignmentManagerOnCluster/testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState/
{code}java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.AssignmentManager.regionOnline(AssignmentManager.java:1314)
at
org.apache.hadoop.hbase.master.TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState(TestAssignmentManagerOnCluster.java:482)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74){code}
Hope you don't mind my assigning it to you Jimmy. Thought you might be
interested.
--
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-6826) [WINDOWS] TestFromClientSide failures
[
https://issues.apache.org/jira/browse/HBASE-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722676#comment-13722676
]
Lars Hofhansl commented on HBASE-6826:
--
Committed to 0.94 as well.
[WINDOWS] TestFromClientSide failures
-
Key: HBASE-6826
URL: https://issues.apache.org/jira/browse/HBASE-6826
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.3, 0.95.2
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Labels: windows
Fix For: 0.95.0, 0.94.11
Attachments: hbase-6826_v1-0.94.patch, hbase-6826_v1-trunk.patch,
hbase-6826_v2-0.94.patch, hbase-6826_v2-trunk.patch
The following tests fail for TestFromClientSide:
{code}
testPoolBehavior()
testClientPoolRoundRobin()
testClientPoolThreadLocal()
{code}
The first test fails due to the fact that the test (wrongly) assumes that
ThredPoolExecutor can reclaim the thread immediately.
The second and third tests seem to fail because that Put's to the table does
not specify an explicit timestamp, but on windows, consecutive calls to put
happen to finish in the same milisecond so that the resulting mutations have
the same timestamp, thus there is only one version of the cell 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-9063) TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState fails
[
https://issues.apache.org/jira/browse/HBASE-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722689#comment-13722689
]
stack commented on HBASE-9063:
--
+1 Jimmy. Thanks. Leave it open for now I'd say.
TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState
fails
Key: HBASE-9063
URL: https://issues.apache.org/jira/browse/HBASE-9063
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
Assignee: Jimmy Xiang
Attachments: trunk-9063.patch
https://builds.apache.org/job/hbase-0.95-on-hadoop2/200/testReport/org.apache.hadoop.hbase.master/TestAssignmentManagerOnCluster/testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState/
{code}java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.AssignmentManager.regionOnline(AssignmentManager.java:1314)
at
org.apache.hadoop.hbase.master.TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState(TestAssignmentManagerOnCluster.java:482)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74){code}
Hope you don't mind my assigning it to you Jimmy. Thought you might be
interested.
--
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-9012) TestBlockReorder.testBlockLocationReorder fails
[
https://issues.apache.org/jira/browse/HBASE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722686#comment-13722686
]
Nicolas Liochon commented on HBASE-9012:
I think it's because the datanode didn't die. The call to shutdown is supposed
to be synchronous, so I'm not sure it's gonna help. In the hdfs javadoc, there
is this:
{quote}
org.apache.hadoop.hdfs.server.datanode.DataNode
public void shutdown()
Shut down this instance of the datanode. Returns only after shutdown is
complete. This method can only be called by the offerService thread. Otherwise,
deadlock might occur
{quote}
This method can only be called by the offerService thread is strange, but
when I look at the code I don't see what it means
(MiniDFSCluster#shutdownDataNodes) does not do anything special with threads.
TestBlockReorder.testBlockLocationReorder fails
---
Key: HBASE-9012
URL: https://issues.apache.org/jira/browse/HBASE-9012
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
Assignee: stack
Fix For: 0.95.2
Attachments: 9012.txt
http://54.241.6.143/job/HBase-0.95/669/org.apache.hbase$hbase-server/testReport/junit/org.apache.hadoop.hbase.fs/TestBlockReorder/testBlockLocationReorder/
java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383)
at java.net.ServerSocket.bind(ServerSocket.java:328)
at java.net.ServerSocket.init(ServerSocket.java:194)
at java.net.ServerSocket.init(ServerSocket.java:106)
at
org.apache.hadoop.hbase.fs.TestBlockReorder.testBlockLocationReorder(TestBlockReorder.java:182)
--
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-9063) TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState fails
[
https://issues.apache.org/jira/browse/HBASE-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-9063:
---
Status: Open (was: Patch Available)
Sure. Integrated the patch to trunk and 0.95. Will leave the issue open.
TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState
fails
Key: HBASE-9063
URL: https://issues.apache.org/jira/browse/HBASE-9063
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
Assignee: Jimmy Xiang
Attachments: trunk-9063.patch
https://builds.apache.org/job/hbase-0.95-on-hadoop2/200/testReport/org.apache.hadoop.hbase.master/TestAssignmentManagerOnCluster/testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState/
{code}java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.AssignmentManager.regionOnline(AssignmentManager.java:1314)
at
org.apache.hadoop.hbase.master.TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState(TestAssignmentManagerOnCluster.java:482)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74){code}
Hope you don't mind my assigning it to you Jimmy. Thought you might be
interested.
--
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-9012) TestBlockReorder.testBlockLocationReorder fails
[ https://issues.apache.org/jira/browse/HBASE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722715#comment-13722715 ] stack commented on HBASE-9012: -- [~liochon] (Welcome back) Now I see that we are just retrying same port over and over. I thought port number was incrementing. Yeah, why is the dn so obstreperous. You looking in logs? Does it go down eventually? TestBlockReorder.testBlockLocationReorder fails --- Key: HBASE-9012 URL: https://issues.apache.org/jira/browse/HBASE-9012 Project: HBase Issue Type: Bug Components: test Reporter: stack Assignee: stack Fix For: 0.95.2 Attachments: 9012.txt http://54.241.6.143/job/HBase-0.95/669/org.apache.hbase$hbase-server/testReport/junit/org.apache.hadoop.hbase.fs/TestBlockReorder/testBlockLocationReorder/ java.net.BindException: Address already in use at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) at java.net.ServerSocket.bind(ServerSocket.java:328) at java.net.ServerSocket.init(ServerSocket.java:194) at java.net.ServerSocket.init(ServerSocket.java:106) at org.apache.hadoop.hbase.fs.TestBlockReorder.testBlockLocationReorder(TestBlockReorder.java:182) -- 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-9012) TestBlockReorder.testBlockLocationReorder fails
[ https://issues.apache.org/jira/browse/HBASE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722735#comment-13722735 ] Nicolas Liochon commented on HBASE-9012: Hi Stack :-) Actually there is another scenario: another process / test took the port between the time we killed and the time we try to take the port. I'm not sure it's that scenario, because usually the OS is supposed to wait a little before allocating the same port. But who knows? So we could fix this by checking that we've been able to take the port, and if not, skip the next step? This could work as well if the DN is still there, whatever the reason. If you're ok with the approach I will write a patch. TestBlockReorder.testBlockLocationReorder fails --- Key: HBASE-9012 URL: https://issues.apache.org/jira/browse/HBASE-9012 Project: HBase Issue Type: Bug Components: test Reporter: stack Assignee: stack Fix For: 0.95.2 Attachments: 9012.txt http://54.241.6.143/job/HBase-0.95/669/org.apache.hbase$hbase-server/testReport/junit/org.apache.hadoop.hbase.fs/TestBlockReorder/testBlockLocationReorder/ java.net.BindException: Address already in use at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) at java.net.ServerSocket.bind(ServerSocket.java:328) at java.net.ServerSocket.init(ServerSocket.java:194) at java.net.ServerSocket.init(ServerSocket.java:106) at org.apache.hadoop.hbase.fs.TestBlockReorder.testBlockLocationReorder(TestBlockReorder.java:182) -- 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-9073) Up retries on TestSnapshotFromMaster; retries only once
stack created HBASE-9073: Summary: Up retries on TestSnapshotFromMaster; retries only once Key: HBASE-9073 URL: https://issues.apache.org/jira/browse/HBASE-9073 Project: HBase Issue Type: Sub-task Components: test Reporter: stack -- 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-9072) TestSnapshotFromMaster.testSnapshotHFileArchiving fails
[
https://issues.apache.org/jira/browse/HBASE-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-9072:
-
Attachment: 9072.txt
Up retries. I tried it locally and it passes.
TestSnapshotFromMaster.testSnapshotHFileArchiving fails
---
Key: HBASE-9072
URL: https://issues.apache.org/jira/browse/HBASE-9072
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/428/testReport/junit/org.apache.hadoop.hbase.master.cleaner/TestSnapshotFromMaster/testSnapshotHFileArchiving/
{code}
Failed 4600 actions: SocketTimeoutException: 4600 times,
Stacktrace
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed
4600 actions: SocketTimeoutException: 4600 times,
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:157)
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$500(AsyncProcess.java:145)
at
org.apache.hadoop.hbase.client.AsyncProcess.getErrors(AsyncProcess.java:700)
at
org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:827)
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{code}
[~mbertozzi] Opinion?
--
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-9072) TestSnapshotFromMaster.testSnapshotHFileArchiving fails
[
https://issues.apache.org/jira/browse/HBASE-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-9072:
-
Attachment: (was: 9072.txt)
TestSnapshotFromMaster.testSnapshotHFileArchiving fails
---
Key: HBASE-9072
URL: https://issues.apache.org/jira/browse/HBASE-9072
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/428/testReport/junit/org.apache.hadoop.hbase.master.cleaner/TestSnapshotFromMaster/testSnapshotHFileArchiving/
{code}
Failed 4600 actions: SocketTimeoutException: 4600 times,
Stacktrace
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed
4600 actions: SocketTimeoutException: 4600 times,
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:157)
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$500(AsyncProcess.java:145)
at
org.apache.hadoop.hbase.client.AsyncProcess.getErrors(AsyncProcess.java:700)
at
org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:827)
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{code}
[~mbertozzi] Opinion?
--
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-9073) Up retries on TestSnapshotFromMaster; retries only once
[ https://issues.apache.org/jira/browse/HBASE-9073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-9073: - Attachment: 9073.txt Up retries Up retries on TestSnapshotFromMaster; retries only once --- Key: HBASE-9073 URL: https://issues.apache.org/jira/browse/HBASE-9073 Project: HBase Issue Type: Sub-task Components: test Reporter: stack Attachments: 9073.txt -- 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-9072) TestSnapshotFromMaster.testSnapshotHFileArchiving fails
[
https://issues.apache.org/jira/browse/HBASE-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722747#comment-13722747
]
stack commented on HBASE-9072:
--
Let me put the patch on the subtask so I can leave this issue open.
TestSnapshotFromMaster.testSnapshotHFileArchiving fails
---
Key: HBASE-9072
URL: https://issues.apache.org/jira/browse/HBASE-9072
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/428/testReport/junit/org.apache.hadoop.hbase.master.cleaner/TestSnapshotFromMaster/testSnapshotHFileArchiving/
{code}
Failed 4600 actions: SocketTimeoutException: 4600 times,
Stacktrace
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed
4600 actions: SocketTimeoutException: 4600 times,
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:157)
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$500(AsyncProcess.java:145)
at
org.apache.hadoop.hbase.client.AsyncProcess.getErrors(AsyncProcess.java:700)
at
org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:827)
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{code}
[~mbertozzi] Opinion?
--
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-8846) Revert the package name change for TableExistsException
[ https://issues.apache.org/jira/browse/HBASE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devaraj Das updated HBASE-8846: --- Attachment: 8846-3.txt Fixes tests.. Revert the package name change for TableExistsException --- Key: HBASE-8846 URL: https://issues.apache.org/jira/browse/HBASE-8846 Project: HBase Issue Type: Bug Affects Versions: 0.95.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.95.2 Attachments: 8846-1.txt, 8846-2.txt, 8846-3.txt I was going through the code changes that were needed for getting an application that was running with hbase-0.92 run with hbase-0.95. TableExistsException's package has changed - hence, needs a code change in the application. Offline discussion with some folks led us to believe that this change can probably be reverted back. -- 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-9072) TestSnapshotFromMaster.testSnapshotHFileArchiving fails
[
https://issues.apache.org/jira/browse/HBASE-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722755#comment-13722755
]
stack commented on HBASE-9072:
--
I upped the retries down in HBASE-9073. Lets see if this helps. Thanks
[~mbertozzi]
TestSnapshotFromMaster.testSnapshotHFileArchiving fails
---
Key: HBASE-9072
URL: https://issues.apache.org/jira/browse/HBASE-9072
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/428/testReport/junit/org.apache.hadoop.hbase.master.cleaner/TestSnapshotFromMaster/testSnapshotHFileArchiving/
{code}
Failed 4600 actions: SocketTimeoutException: 4600 times,
Stacktrace
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed
4600 actions: SocketTimeoutException: 4600 times,
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:157)
at
org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$500(AsyncProcess.java:145)
at
org.apache.hadoop.hbase.client.AsyncProcess.getErrors(AsyncProcess.java:700)
at
org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:827)
at org.apache.hadoop.hbase.client.HTable.doPut(HTable.java:794)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:756)
at
org.apache.hadoop.hbase.HBaseTestingUtility.loadTable(HBaseTestingUtility.java:1312)
at
org.apache.hadoop.hbase.master.cleaner.TestSnapshotFromMaster.testSnapshotHFileArchiving(TestSnapshotFromMaster.java:297)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{code}
[~mbertozzi] Opinion?
--
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] [Resolved] (HBASE-9073) Up retries on TestSnapshotFromMaster; retries only once
[ https://issues.apache.org/jira/browse/HBASE-9073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-9073. -- Resolution: Fixed Fix Version/s: 0.95.2 0.98.0 Committed to trunk and 0.95. Up retries on TestSnapshotFromMaster; retries only once --- Key: HBASE-9073 URL: https://issues.apache.org/jira/browse/HBASE-9073 Project: HBase Issue Type: Sub-task Components: test Reporter: stack Fix For: 0.98.0, 0.95.2 Attachments: 9073.txt -- 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-9012) TestBlockReorder.testBlockLocationReorder fails
[ https://issues.apache.org/jira/browse/HBASE-9012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722769#comment-13722769 ] stack commented on HBASE-9012: -- Sounds good [~liochon] Thanks. TestBlockReorder.testBlockLocationReorder fails --- Key: HBASE-9012 URL: https://issues.apache.org/jira/browse/HBASE-9012 Project: HBase Issue Type: Bug Components: test Reporter: stack Assignee: stack Fix For: 0.95.2 Attachments: 9012.txt http://54.241.6.143/job/HBase-0.95/669/org.apache.hbase$hbase-server/testReport/junit/org.apache.hadoop.hbase.fs/TestBlockReorder/testBlockLocationReorder/ java.net.BindException: Address already in use at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:383) at java.net.ServerSocket.bind(ServerSocket.java:328) at java.net.ServerSocket.init(ServerSocket.java:194) at java.net.ServerSocket.init(ServerSocket.java:106) at org.apache.hadoop.hbase.fs.TestBlockReorder.testBlockLocationReorder(TestBlockReorder.java:182) -- 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-9066) TestReplicationTrackerZKImpl fails
[ https://issues.apache.org/jira/browse/HBASE-9066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722773#comment-13722773 ] Chris Trezzo commented on HBASE-9066: - Thanks [~saint@gmail.com] will take a look. TestReplicationTrackerZKImpl fails -- Key: HBASE-9066 URL: https://issues.apache.org/jira/browse/HBASE-9066 Project: HBase Issue Type: Bug Components: test Reporter: stack Assignee: Chris Trezzo This new test has failed a few times over last day or so. Here is a sample w/ two fails in it. http://54.241.6.143/job/HBase-0.95/707/ Hope you don't mind me assigning it to you Chris. I'm going to disable these two tests for now so can get some good test runs in over the w/e. Thanks boss. -- 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-9034) hbase-daemon.sh swallows start up errors
[ https://issues.apache.org/jira/browse/HBASE-9034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722783#comment-13722783 ] Jean-Daniel Cryans commented on HBASE-9034: --- It's still not how it used to work. hbase-daemon.sh swallows start up errors Key: HBASE-9034 URL: https://issues.apache.org/jira/browse/HBASE-9034 Project: HBase Issue Type: Bug Components: scripts Affects Versions: 0.98.0, 0.95.1 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.98.0, 0.95.2 Attachments: HBASE-9034-0.patch, HBASE-9034-ADD.patch Fix it so that start up errors go into .out. -- 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-9052) Prevent split/merged region from assigning again
[ https://issues.apache.org/jira/browse/HBASE-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-9052: --- Attachment: trunk-9052.patch Prevent split/merged region from assigning again Key: HBASE-9052 URL: https://issues.apache.org/jira/browse/HBASE-9052 Project: HBase Issue Type: Bug Components: Region Assignment Affects Versions: 0.95.1 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Attachments: trunk-9052.patch If a region is split/merged, before it's removed from meta, you can still assign it from the HBase shell. It's better to prevent this from happening. -- 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-8940) TestRegionMergeTransactionOnCluster#testWholesomeMerge may fail due to race in opening region
[
https://issues.apache.org/jira/browse/HBASE-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722792#comment-13722792
]
stack commented on HBASE-8940:
--
+1
Thanks.
TestRegionMergeTransactionOnCluster#testWholesomeMerge may fail due to race
in opening region
-
Key: HBASE-8940
URL: https://issues.apache.org/jira/browse/HBASE-8940
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
Assignee: chunhui shen
Fix For: 0.95.2
Attachments: 8940-addendum.patch, 8940-trunk-v2.patch, 8940-v1.txt,
8940v3.txt
From
http://54.241.6.143/job/HBase-TRUNK-Hadoop-2/org.apache.hbase$hbase-server/395/testReport/org.apache.hadoop.hbase.regionserver/TestRegionMergeTransactionOnCluster/testWholesomeMerge/
:
{code}
013-07-11 09:33:44,154 INFO [AM.ZK.Worker-pool-2-thread-2]
master.RegionStates(309): Offlined 3ffefd878a234031675de6b2c70b2ead from
ip-10-174-118-204.us-west-1.compute.internal,60498,1373535184820
2013-07-11 09:33:44,154 INFO [AM.ZK.Worker-pool-2-thread-2]
master.AssignmentManager$4(1223): The master has opened
testWholesomeMerge,testRow0020,1373535210125.3ffefd878a234031675de6b2c70b2ead.
that was online on
ip-10-174-118-204.us-west-1.compute.internal,59210,1373535184884
2013-07-11 09:33:44,182 DEBUG [RS_OPEN_REGION-ip-10-174-118-204:59210-1]
zookeeper.ZKAssign(862): regionserver:59210-0x13fcd13a20c0002 Successfully
transitioned node 3ffefd878a234031675de6b2c70b2ead from RS_ZK_REGION_OPENING
to RS_ZK_REGION_OPENED
2013-07-11 09:33:44,182 INFO
[MASTER_TABLE_OPERATIONS-ip-10-174-118-204:39405-0]
handler.DispatchMergingRegionHandler(154): Failed send MERGE REGIONS RPC to
server ip-10-174-118-204.us-west-1.compute.internal,59210,1373535184884 for
region
testWholesomeMerge,,1373535210124.efcb10dcfa250e31bfd50dc6c7049f32.,testWholesomeMerge,testRow0020,1373535210125.3ffefd878a234031675de6b2c70b2ead.,
focible=false, org.apache.hadoop.hbase.exceptions.RegionOpeningException:
Region is being opened: 3ffefd878a234031675de6b2c70b2ead
at
org.apache.hadoop.hbase.regionserver.HRegionServer.getRegionByEncodedName(HRegionServer.java:2566)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.getRegion(HRegionServer.java:3862)
at
org.apache.hadoop.hbase.regionserver.HRegionServer.mergeRegions(HRegionServer.java:3649)
at
org.apache.hadoop.hbase.protobuf.generated.AdminProtos$AdminService$2.callBlockingMethod(AdminProtos.java:14400)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2124)
at
org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1831)
2013-07-11 09:33:44,182 DEBUG [RS_OPEN_REGION-ip-10-174-118-204:59210-1]
handler.OpenRegionHandler(373): region transitioned to opened in zookeeper:
{ENCODED = 3ffefd878a234031675de6b2c70b2ead, NAME =
'testWholesomeMerge,testRow0020,1373535210125.3ffefd878a234031675de6b2c70b2ead.',
STARTKEY = 'testRow0020', ENDKEY = 'testRow0040'}, server:
ip-10-174-118-204.us-west-1.compute.internal,59210,1373535184884
2013-07-11 09:33:44,183 DEBUG [RS_OPEN_REGION-ip-10-174-118-204:59210-1]
handler.OpenRegionHandler(186): Opened
testWholesomeMerge,testRow0020,1373535210125.3ffefd878a234031675de6b2c70b2ead.
on server:ip-10-174-118-204.us-west-1.compute.internal,59210,1373535184884
{code}
We can see that MASTER_TABLE_OPERATIONS thread couldn't get region
3ffefd878a234031675de6b2c70b2ead because RS_OPEN_REGION thread finished
region opening 1 millisecond later.
One solution is to retry operation when receiving RegionOpeningException
--
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-9063) TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState fails
[
https://issues.apache.org/jira/browse/HBASE-9063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722796#comment-13722796
]
Hadoop QA commented on HBASE-9063:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12594736/trunk-9063.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6510//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6510//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6510//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6510//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6510//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6510//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6510//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6510//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6510//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6510//console
This message is automatically generated.
TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState
fails
Key: HBASE-9063
URL: https://issues.apache.org/jira/browse/HBASE-9063
Project: HBase
Issue Type: Bug
Components: test
Reporter: stack
Assignee: Jimmy Xiang
Attachments: trunk-9063.patch
https://builds.apache.org/job/hbase-0.95-on-hadoop2/200/testReport/org.apache.hadoop.hbase.master/TestAssignmentManagerOnCluster/testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState/
{code}java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.AssignmentManager.regionOnline(AssignmentManager.java:1314)
at
org.apache.hadoop.hbase.master.TestAssignmentManagerOnCluster.testSSHWhenDisablingTableRegionsInOpeningOrPendingOpenState(TestAssignmentManagerOnCluster.java:482)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74){code}
Hope you don't mind my assigning it to you Jimmy. Thought you might be
interested.
--
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:
[jira] [Updated] (HBASE-9034) hbase-daemon.sh swallows start up errors
[ https://issues.apache.org/jira/browse/HBASE-9034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9034: - Attachment: HBASE-9034-ADD-1.patch Here's what I'm going to commit. JD noticed that starting servername wasn't showing up so I moved that too. hbase-daemon.sh swallows start up errors Key: HBASE-9034 URL: https://issues.apache.org/jira/browse/HBASE-9034 Project: HBase Issue Type: Bug Components: scripts Affects Versions: 0.98.0, 0.95.1 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.98.0, 0.95.2 Attachments: HBASE-9034-0.patch, HBASE-9034-ADD-1.patch, HBASE-9034-ADD.patch Fix it so that start up errors go into .out. -- 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-8615) TestReplicationQueueFailoverCompressed#queueFailover fails on hadoop 2.0 due to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/HBASE-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722807#comment-13722807
]
Jean-Daniel Cryans commented on HBASE-8615:
---
It's just the compression test that fails FWIW, so it seems that something is
broken in HLog compression or the way we read them.
TestReplicationQueueFailoverCompressed#queueFailover fails on hadoop 2.0 due
to IndexOutOfBoundsException
-
Key: HBASE-8615
URL: https://issues.apache.org/jira/browse/HBASE-8615
Project: HBase
Issue Type: Bug
Components: Replication
Reporter: Ted Yu
Assignee: Jean-Daniel Cryans
Attachments:
org.apache.hadoop.hbase.replication.TestReplicationQueueFailoverCompressed-output.txt
In a recent test run, I noticed the following in test output:
{code}
2013-05-24 22:01:02,424 DEBUG
[RegionServer:0;kiyo.gq1.ygridcore.net,42690,1369432806911.replicationSource,2]
fs.HFileSystem$ReorderWALBlocks(327):
/user/hortonzy/hbase/.logs/kiyo.gq1.ygridcore.net,42690,1369432806911/kiyo.gq1.ygridcore.net%2C42690%2C1369432806911.1369432840428
is an HLog file, so reordering blocks, last hostname will
be:kiyo.gq1.ygridcore.net
2013-05-24 22:01:02,429 DEBUG
[RegionServer:0;kiyo.gq1.ygridcore.net,42690,1369432806911.replicationSource,2]
wal.ProtobufLogReader(118): After reading the trailer: walEditsStopOffset:
132235, fileLength: 132243, trailerPresent: true
2013-05-24 22:01:02,438 ERROR
[RegionServer:0;kiyo.gq1.ygridcore.net,42690,1369432806911.replicationSource,2]
wal.ProtobufLogReader(236): Error while reading 691 WAL KVs; started
reading at 53272 and read up to 65538
2013-05-24 22:01:02,438 WARN
[RegionServer:0;kiyo.gq1.ygridcore.net,42690,1369432806911.replicationSource,2]
regionserver.ReplicationSource(324): 2 Got:
java.io.IOException: Error while reading 691 WAL KVs; started reading at
53272 and read up to 65538
at
org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader.readNext(ProtobufLogReader.java:237)
at
org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:96)
at
org.apache.hadoop.hbase.replication.regionserver.ReplicationHLogReaderManager.readNextAndSetPosition(ReplicationHLogReaderManager.java:89)
at
org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.readAllEntriesToReplicateOrNextFile(ReplicationSource.java:404)
at
org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.run(ReplicationSource.java:320)
Caused by: java.lang.IndexOutOfBoundsException: index (30062) must be less
than size (1)
at
com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:305)
at
com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:284)
at
org.apache.hadoop.hbase.regionserver.wal.LRUDictionary$BidirectionalLRUMap.get(LRUDictionary.java:124)
at
org.apache.hadoop.hbase.regionserver.wal.LRUDictionary$BidirectionalLRUMap.access$000(LRUDictionary.java:71)
at
org.apache.hadoop.hbase.regionserver.wal.LRUDictionary.getEntry(LRUDictionary.java:42)
at
org.apache.hadoop.hbase.regionserver.wal.WALCellCodec$CompressedKvDecoder.readIntoArray(WALCellCodec.java:210)
at
org.apache.hadoop.hbase.regionserver.wal.WALCellCodec$CompressedKvDecoder.parseCell(WALCellCodec.java:184)
at
org.apache.hadoop.hbase.codec.BaseDecoder.advance(BaseDecoder.java:46)
at
org.apache.hadoop.hbase.regionserver.wal.WALEdit.readFromCells(WALEdit.java:213)
at
org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader.readNext(ProtobufLogReader.java:217)
... 4 more
2013-05-24 22:01:02,439 DEBUG
[RegionServer:0;kiyo.gq1.ygridcore.net,42690,1369432806911.replicationSource,2]
regionserver.ReplicationSource(583): Nothing to replicate, sleeping 100
times 10
{code}
Will attach test output.
--
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-9034) hbase-daemon.sh swallows start up errors
[ https://issues.apache.org/jira/browse/HBASE-9034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722815#comment-13722815 ] Jean-Daniel Cryans commented on HBASE-9034: --- +1 thanks Elliott hbase-daemon.sh swallows start up errors Key: HBASE-9034 URL: https://issues.apache.org/jira/browse/HBASE-9034 Project: HBase Issue Type: Bug Components: scripts Affects Versions: 0.98.0, 0.95.1 Reporter: Elliott Clark Assignee: Elliott Clark Fix For: 0.98.0, 0.95.2 Attachments: HBASE-9034-0.patch, HBASE-9034-ADD-1.patch, HBASE-9034-ADD.patch Fix it so that start up errors go into .out. -- 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] [Resolved] (HBASE-9032) Result.getBytes() returns null if backed by KeyValue array
[ https://issues.apache.org/jira/browse/HBASE-9032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-9032. -- Resolution: Fixed Hadoop Flags: Reviewed I like [~lhofhansl] take that this should never have been public. Given that it is and that it sometimes is broke, I committed the patch to 0.94 trunk. Thanks Aditya. Result.getBytes() returns null if backed by KeyValue array -- Key: HBASE-9032 URL: https://issues.apache.org/jira/browse/HBASE-9032 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.94.9 Reporter: Aditya Kishore Assignee: Aditya Kishore Fix For: 0.94.11 Attachments: HBASE-9032.patch, HBASE-9032.patch, HBASE-9032.patch, HBASE-9032.patch This applies only to 0.94 (and earlier) branch. If the Result object was constructed using either of Result(KeyValue[]) or Result(ListKeyValue), calling Result.getBytes() returns null instead of the serialized ImmutableBytesWritable object. -- 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-9052) Prevent split/merged region from assigning again
[ https://issues.apache.org/jira/browse/HBASE-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jimmy Xiang updated HBASE-9052: --- Status: Patch Available (was: Open) Attached a patch which moves split region to SPLIT state, merged region to MERGED state, so they won't be assigned any more unless its state is changed. Prevent split/merged region from assigning again Key: HBASE-9052 URL: https://issues.apache.org/jira/browse/HBASE-9052 Project: HBase Issue Type: Bug Components: Region Assignment Affects Versions: 0.95.1 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Attachments: trunk-9052.patch If a region is split/merged, before it's removed from meta, you can still assign it from the HBase shell. It's better to prevent this from happening. -- 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-8846) Revert the package name change for TableExistsException
[
https://issues.apache.org/jira/browse/HBASE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722867#comment-13722867
]
Hadoop QA commented on HBASE-8846:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12594750/8846-3.txt
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 184
new or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6511//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6511//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6511//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6511//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6511//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6511//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6511//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6511//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6511//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6511//console
This message is automatically generated.
Revert the package name change for TableExistsException
---
Key: HBASE-8846
URL: https://issues.apache.org/jira/browse/HBASE-8846
Project: HBase
Issue Type: Bug
Affects Versions: 0.95.0
Reporter: Devaraj Das
Assignee: Devaraj Das
Fix For: 0.95.2
Attachments: 8846-1.txt, 8846-2.txt, 8846-3.txt
I was going through the code changes that were needed for getting an
application that was running with hbase-0.92 run with hbase-0.95.
TableExistsException's package has changed - hence, needs a code change in
the application. Offline discussion with some folks led us to believe that
this change can probably be reverted back.
--
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-8768) Improve bulk load performance by moving key value construction from map phase to reduce phase.
[
https://issues.apache.org/jira/browse/HBASE-8768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722890#comment-13722890
]
Ted Yu commented on HBASE-8768:
---
For TextSortReducer, please add stability and audience annotation.
{code}
+ * @see HFIleOutputFormat
{code}
Typo above.
{code}
+while (iter.hasNext()) {
+ TreeSetKeyValue map = new TreeSetKeyValue(KeyValue.COMPARATOR);
{code}
Why is a new map created in each iteration of the loop ?
Since the map is backed by TreeSet, maybe just call it set ?
{code}
+return;
+ } else {
+throw new IOException(badLine);
{code}
The else keyword can be omitted.
{code}
+if (index 0 index % 100 == 0)
+ context.setStatus(Wrote + index);
{code}
Please complete the sentence above.
{code}
+public class TsvImporterTextMapper
{code}
Add stability and audience annotation.
{code}
+} catch (InterruptedException e) {
+ e.printStackTrace();
+}
{code}
Restore interrupt state.
{code}
+ public void testBulkOutputwithTsvImporterTextMapper() throws Exception {
{code}
Please upper case the 'w' in 'with'
Improve bulk load performance by moving key value construction from map phase
to reduce phase.
--
Key: HBASE-8768
URL: https://issues.apache.org/jira/browse/HBASE-8768
Project: HBase
Issue Type: Improvement
Components: mapreduce, Performance
Reporter: rajeshbabu
Assignee: rajeshbabu
Fix For: 0.98.0, 0.95.2
Attachments: HBASE-8768_v2.patch, HBASE-8768_v3.patch,
HBase_Bulkload_Performance_Improvement.pdf
ImportTSV bulkloading approach uses MapReduce framework. Existing mapper and
reducer classes used by ImportTSV are TsvImporterMapper.java and
PutSortReducer.java. ImportTSV tool parses the tab(by default) seperated
values from the input files and Mapper class generates the PUT objects for
each row using the Key value pairs created from the parsed text.
PutSortReducer then uses the partions based on the regions and sorts the Put
objects for each region.
Overheads we can see in the above approach:
==
1) keyvalue construction for each parsed value in the line adding extra data
like rowkey,columnfamily,qualifier which will increase around 5x extra data
to be shuffled in reduce phase.
We can calculate data size to shuffled as below
{code}
Data to be shuffled = nl*nt*(rl+cfl+cql+vall+tsl+30)
{code}
If we move keyvalue construction to reduce phase we datasize to be shuffle
will be which is very less compared to above.
{code}
Data to be shuffled = nl*nt*vall
{code}
nl - Number of lines in the raw file
nt - Number of tabs or columns including row key.
rl - row length which will be different for each line.
cfl - column family length which will be different for each family
cql - qualifier length
tsl - timestamp length.
vall- each parsed value length.
30 bytes for kv size,number of families etc.
2) In mapper side we are creating put objects by adding all keyvalues
constructed for each line and in reducer we will again collect keyvalues from
put and sort them.
Instead we can directly create and sort keyvalues in reducer.
Solution:
We can improve bulk load performance by moving the key value construction
from mapper to reducer so that Mapper just sends the raw text for each row to
the Reducer. Reducer then parses the records for rows and create and sort the
key value pairs before writing to HFiles.
Conclusion:
===
The above suggestions will improve map phase performance by avoiding keyvalue
construction and reduce phase performance by avoiding excess data to be
shuffled.
--
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-8846) Revert the package name change for TableExistsException
[ https://issues.apache.org/jira/browse/HBASE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722895#comment-13722895 ] stack commented on HBASE-8846: -- For sure we are moving exceptions back to their original positions? Revert the package name change for TableExistsException --- Key: HBASE-8846 URL: https://issues.apache.org/jira/browse/HBASE-8846 Project: HBase Issue Type: Bug Affects Versions: 0.95.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.95.2 Attachments: 8846-1.txt, 8846-2.txt, 8846-3.txt I was going through the code changes that were needed for getting an application that was running with hbase-0.92 run with hbase-0.95. TableExistsException's package has changed - hence, needs a code change in the application. Offline discussion with some folks led us to believe that this change can probably be reverted back. -- 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-9074) TestAdmin.testMoveToPreviouslyAssignedRS fails
Jimmy Xiang created HBASE-9074:
--
Summary: TestAdmin.testMoveToPreviouslyAssignedRS fails
Key: HBASE-9074
URL: https://issues.apache.org/jira/browse/HBASE-9074
Project: HBase
Issue Type: Test
Components: test
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
http://54.241.6.143/job/HBase-0.95/org.apache.hbase$hbase-server/716/testReport/org.apache.hadoop.hbase.client/TestAdmin/testMoveToPreviouslyAssignedRS/
{noformat}
java.lang.NullPointerException
at
org.apache.hadoop.hbase.client.TestAdmin.testMoveToPreviouslyAssignedRS(TestAdmin.java:1567)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
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-9074) TestAdmin.testMoveToPreviouslyAssignedRS fails
[
https://issues.apache.org/jira/browse/HBASE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-9074:
---
Attachment: trunk-9074.patch
TestAdmin.testMoveToPreviouslyAssignedRS fails
--
Key: HBASE-9074
URL: https://issues.apache.org/jira/browse/HBASE-9074
Project: HBase
Issue Type: Test
Components: test
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
Attachments: trunk-9074.patch
http://54.241.6.143/job/HBase-0.95/org.apache.hbase$hbase-server/716/testReport/org.apache.hadoop.hbase.client/TestAdmin/testMoveToPreviouslyAssignedRS/
{noformat}
java.lang.NullPointerException
at
org.apache.hadoop.hbase.client.TestAdmin.testMoveToPreviouslyAssignedRS(TestAdmin.java:1567)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
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-9074) TestAdmin.testMoveToPreviouslyAssignedRS fails
[
https://issues.apache.org/jira/browse/HBASE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722916#comment-13722916
]
Ted Yu commented on HBASE-9074:
---
{code}
+assertTrue(The region should be assigned properly,
am.waitForAssignment(hri));
{code}
Mind logging the region name in the message ?
TestAdmin.testMoveToPreviouslyAssignedRS fails
--
Key: HBASE-9074
URL: https://issues.apache.org/jira/browse/HBASE-9074
Project: HBase
Issue Type: Test
Components: test
Affects Versions: 0.98.0, 0.95.2
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
Attachments: trunk-9074.patch
http://54.241.6.143/job/HBase-0.95/org.apache.hbase$hbase-server/716/testReport/org.apache.hadoop.hbase.client/TestAdmin/testMoveToPreviouslyAssignedRS/
{noformat}
java.lang.NullPointerException
at
org.apache.hadoop.hbase.client.TestAdmin.testMoveToPreviouslyAssignedRS(TestAdmin.java:1567)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
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-9074) TestAdmin.testMoveToPreviouslyAssignedRS fails
[
https://issues.apache.org/jira/browse/HBASE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-9074:
---
Affects Version/s: 0.95.2
0.98.0
Status: Patch Available (was: Open)
Attached a patch to make sure the region is assigned before we get the server
it's assigned to.
TestAdmin.testMoveToPreviouslyAssignedRS fails
--
Key: HBASE-9074
URL: https://issues.apache.org/jira/browse/HBASE-9074
Project: HBase
Issue Type: Test
Components: test
Affects Versions: 0.98.0, 0.95.2
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
Attachments: trunk-9074.patch
http://54.241.6.143/job/HBase-0.95/org.apache.hbase$hbase-server/716/testReport/org.apache.hadoop.hbase.client/TestAdmin/testMoveToPreviouslyAssignedRS/
{noformat}
java.lang.NullPointerException
at
org.apache.hadoop.hbase.client.TestAdmin.testMoveToPreviouslyAssignedRS(TestAdmin.java:1567)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
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-9032) Result.getBytes() returns null if backed by KeyValue array
[ https://issues.apache.org/jira/browse/HBASE-9032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722921#comment-13722921 ] Aditya Kishore commented on HBASE-9032: --- Thanks Lars, Stack. Result.getBytes() returns null if backed by KeyValue array -- Key: HBASE-9032 URL: https://issues.apache.org/jira/browse/HBASE-9032 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.94.9 Reporter: Aditya Kishore Assignee: Aditya Kishore Fix For: 0.94.11 Attachments: HBASE-9032.patch, HBASE-9032.patch, HBASE-9032.patch, HBASE-9032.patch This applies only to 0.94 (and earlier) branch. If the Result object was constructed using either of Result(KeyValue[]) or Result(ListKeyValue), calling Result.getBytes() returns null instead of the serialized ImmutableBytesWritable object. -- 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-9074) TestAdmin.testMoveToPreviouslyAssignedRS fails
[
https://issues.apache.org/jira/browse/HBASE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722925#comment-13722925
]
Jimmy Xiang commented on HBASE-9074:
Sure, I can do that in committing the patch. Thanks.
TestAdmin.testMoveToPreviouslyAssignedRS fails
--
Key: HBASE-9074
URL: https://issues.apache.org/jira/browse/HBASE-9074
Project: HBase
Issue Type: Test
Components: test
Affects Versions: 0.98.0, 0.95.2
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
Attachments: trunk-9074.patch
http://54.241.6.143/job/HBase-0.95/org.apache.hbase$hbase-server/716/testReport/org.apache.hadoop.hbase.client/TestAdmin/testMoveToPreviouslyAssignedRS/
{noformat}
java.lang.NullPointerException
at
org.apache.hadoop.hbase.client.TestAdmin.testMoveToPreviouslyAssignedRS(TestAdmin.java:1567)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
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-8846) Revert the package name change for TableExistsException
[ https://issues.apache.org/jira/browse/HBASE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722930#comment-13722930 ] Devaraj Das commented on HBASE-8846: (smile) that was the intent of this jira to have the minimum impact on applications. Also, in a follow up, we could do what has been suggested in regards to deprecation, etc. Revert the package name change for TableExistsException --- Key: HBASE-8846 URL: https://issues.apache.org/jira/browse/HBASE-8846 Project: HBase Issue Type: Bug Affects Versions: 0.95.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.95.2 Attachments: 8846-1.txt, 8846-2.txt, 8846-3.txt I was going through the code changes that were needed for getting an application that was running with hbase-0.92 run with hbase-0.95. TableExistsException's package has changed - hence, needs a code change in the application. Offline discussion with some folks led us to believe that this change can probably be reverted back. -- 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-9074) TestAdmin.testMoveToPreviouslyAssignedRS fails
[
https://issues.apache.org/jira/browse/HBASE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Xiang updated HBASE-9074:
---
Attachment: trunk-9074_v2.patch
TestAdmin.testMoveToPreviouslyAssignedRS fails
--
Key: HBASE-9074
URL: https://issues.apache.org/jira/browse/HBASE-9074
Project: HBase
Issue Type: Test
Components: test
Affects Versions: 0.98.0, 0.95.2
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
Attachments: trunk-9074.patch, trunk-9074_v2.patch
http://54.241.6.143/job/HBase-0.95/org.apache.hbase$hbase-server/716/testReport/org.apache.hadoop.hbase.client/TestAdmin/testMoveToPreviouslyAssignedRS/
{noformat}
java.lang.NullPointerException
at
org.apache.hadoop.hbase.client.TestAdmin.testMoveToPreviouslyAssignedRS(TestAdmin.java:1567)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
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-9075) [0.94] Backport HBASE-5760 Unit tests should write only under /target to 0.94
Enis Soztutar created HBASE-9075: Summary: [0.94] Backport HBASE-5760 Unit tests should write only under /target to 0.94 Key: HBASE-9075 URL: https://issues.apache.org/jira/browse/HBASE-9075 Project: HBase Issue Type: Test Components: test Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 0.94.11 Backporting HBASE-5760 is a good idea. 0.94 tests mess up the root level directory a lot. -- 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-9052) Prevent split/merged region from assigning again
[ https://issues.apache.org/jira/browse/HBASE-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722962#comment-13722962 ] stack commented on HBASE-9052: -- nit: regionOffline should be renamed setRegionOffline or offlineRegion? I suppose you are following the precedent where this operation is done in a method named regionOffline (reads oddly). I see tightening up of allowed states but how are we prevening assign of MERGE and SPLIT? Prevent split/merged region from assigning again Key: HBASE-9052 URL: https://issues.apache.org/jira/browse/HBASE-9052 Project: HBase Issue Type: Bug Components: Region Assignment Affects Versions: 0.95.1 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Attachments: trunk-9052.patch If a region is split/merged, before it's removed from meta, you can still assign it from the HBase shell. It's better to prevent this from happening. -- 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] [Resolved] (HBASE-7522) Tests should not be writing under /tmp/
[ https://issues.apache.org/jira/browse/HBASE-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar resolved HBASE-7522. -- Resolution: Duplicate Duplicate of HBASE-5760. Tests should not be writing under /tmp/ --- Key: HBASE-7522 URL: https://issues.apache.org/jira/browse/HBASE-7522 Project: HBase Issue Type: Bug Affects Versions: 0.94.5, 0.95.2 Reporter: Enis Soztutar As per the discussion http://mail-archives.apache.org/mod_mbox/hbase-dev/201301.mbox/%3CCA%2BRK%3D_BmV%3Dvwws4VeDJVPt6hY7NKCDEafex3XTNam630pQRBbA%40mail.gmail.com%3E, tests should not be writing under /tmp/ directory. TestStoreFile is one of the offending ones. Some of them will be fixed at HBASE-6824. -- 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-9074) TestAdmin.testMoveToPreviouslyAssignedRS fails
[
https://issues.apache.org/jira/browse/HBASE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722965#comment-13722965
]
stack commented on HBASE-9074:
--
+1
TestAdmin.testMoveToPreviouslyAssignedRS fails
--
Key: HBASE-9074
URL: https://issues.apache.org/jira/browse/HBASE-9074
Project: HBase
Issue Type: Test
Components: test
Affects Versions: 0.98.0, 0.95.2
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
Attachments: trunk-9074.patch, trunk-9074_v2.patch
http://54.241.6.143/job/HBase-0.95/org.apache.hbase$hbase-server/716/testReport/org.apache.hadoop.hbase.client/TestAdmin/testMoveToPreviouslyAssignedRS/
{noformat}
java.lang.NullPointerException
at
org.apache.hadoop.hbase.client.TestAdmin.testMoveToPreviouslyAssignedRS(TestAdmin.java:1567)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
{noformat}
--
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-9075) [0.94] Backport HBASE-5760 Unit tests should write only under /target to 0.94
[ https://issues.apache.org/jira/browse/HBASE-9075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-9075: - Attachment: hbase-9075_v1.patch Straightforward backport patch. It also removes TestHRegionInfo#testGetSetOfHTD(). Running the tests now. [0.94] Backport HBASE-5760 Unit tests should write only under /target to 0.94 - Key: HBASE-9075 URL: https://issues.apache.org/jira/browse/HBASE-9075 Project: HBase Issue Type: Test Components: test Reporter: Enis Soztutar Assignee: Enis Soztutar Fix For: 0.94.11 Attachments: hbase-9075_v1.patch Backporting HBASE-5760 is a good idea. 0.94 tests mess up the root level directory a lot. -- 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-7680) implement compaction policy for stripe compactions
[ https://issues.apache.org/jira/browse/HBASE-7680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722982#comment-13722982 ] Sergey Shelukhin commented on HBASE-7680: - Sorry, I was busy with other things lately, let me rebase/resume everything. I think all 3 JIRAs now have +1s so we can commit in experimental state. implement compaction policy for stripe compactions -- Key: HBASE-7680 URL: https://issues.apache.org/jira/browse/HBASE-7680 Project: HBase Issue Type: Sub-task Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Fix For: 0.95.2 Attachments: HBASE-7680-latest-with-dependencies.patch, HBASE-7680-latest-with-dependencies.patch, HBASE-7680-latest-with-dependencies.patch, HBASE-7680-latest-with-dependencies.patch, HBASE-7680-latest-with-dependencies.patch, HBASE-7680-latest-with-dependencies.patch, HBASE-7680-latest-with-dependencies.patch, HBASE-7680-v0.patch, HBASE-7680-v10.patch, HBASE-7680-v10.patch, HBASE-7680-v11.patch, HBASE-7680-v12.patch, HBASE-7680-v13.patch, HBASE-7680-v13.patch, HBASE-7680-v14.patch, HBASE-7680-v1.patch, HBASE-7680-v2.patch, HBASE-7680-v3.patch, HBASE-7680-v4.patch, HBASE-7680-v5.patch, HBASE-7680-v6.patch, HBASE-7680-v7.patch, HBASE-7680-v8.patch, HBASE-7680-v9.patch Bringing into 0.95.2 so gets some consideration -- 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-9076) Throttle log messages for missing peer cluster
[ https://issues.apache.org/jira/browse/HBASE-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David S. Wang updated HBASE-9076: - Summary: Throttle log messages for missing peer cluster (was: Change ) Throttle log messages for missing peer cluster -- Key: HBASE-9076 URL: https://issues.apache.org/jira/browse/HBASE-9076 Project: HBase Issue Type: Improvement Components: Replication Affects Versions: 0.95.1, 0.94.10 Reporter: David S. Wang Assignee: David S. Wang Priority: Trivial If the replication peer is not available, then RS logs get flooded by messages similar to the following: 2013-07-19 11:55:27,964 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,670 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,966 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,672 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,969 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer It would be better to change the log level to DEBUG in order to avoid these messages showing up in the default case. -- 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-9076) Change
David S. Wang created HBASE-9076: Summary: Change Key: HBASE-9076 URL: https://issues.apache.org/jira/browse/HBASE-9076 Project: HBase Issue Type: Improvement Components: Replication Affects Versions: 0.94.10, 0.95.1 Reporter: David S. Wang Assignee: David S. Wang Priority: Trivial If the replication peer is not available, then RS logs get flooded by messages similar to the following: 2013-07-19 11:55:27,964 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,670 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,966 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,672 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,969 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer It would be better to change the log level to DEBUG in order to avoid these messages showing up in the default case. -- 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-9076) Throttle log messages for missing peer cluster
[ https://issues.apache.org/jira/browse/HBASE-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David S. Wang updated HBASE-9076: - Status: Patch Available (was: Open) Throttle log messages for missing peer cluster -- Key: HBASE-9076 URL: https://issues.apache.org/jira/browse/HBASE-9076 Project: HBase Issue Type: Improvement Components: Replication Affects Versions: 0.94.10, 0.95.1 Reporter: David S. Wang Assignee: David S. Wang Priority: Trivial Attachments: HBASE-9076.patch If the replication peer is not available, then RS logs get flooded by messages similar to the following: 2013-07-19 11:55:27,964 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,670 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,966 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,672 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,969 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer It would be better to change the log level to DEBUG in order to avoid these messages showing up in the default case. -- 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-9076) Throttle log messages for missing peer cluster
[ https://issues.apache.org/jira/browse/HBASE-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David S. Wang updated HBASE-9076: - Attachment: HBASE-9076.patch Throttle log messages for missing peer cluster -- Key: HBASE-9076 URL: https://issues.apache.org/jira/browse/HBASE-9076 Project: HBase Issue Type: Improvement Components: Replication Affects Versions: 0.95.1, 0.94.10 Reporter: David S. Wang Assignee: David S. Wang Priority: Trivial Attachments: HBASE-9076.patch If the replication peer is not available, then RS logs get flooded by messages similar to the following: 2013-07-19 11:55:27,964 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,670 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,966 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,672 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,969 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer It would be better to change the log level to DEBUG in order to avoid these messages showing up in the default case. -- 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-8846) Revert the package name change for TableExistsException
[ https://issues.apache.org/jira/browse/HBASE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722992#comment-13722992 ] Enis Soztutar commented on HBASE-8846: -- bq. For sure we are moving exceptions back to their original positions? What do you think Stack? Should not we do this? My understanding is that we should have exceptions be in the same level that they are generated / used. .client for client level exceptions, .regionserver for RS-only exceptions etc. Revert the package name change for TableExistsException --- Key: HBASE-8846 URL: https://issues.apache.org/jira/browse/HBASE-8846 Project: HBase Issue Type: Bug Affects Versions: 0.95.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.95.2 Attachments: 8846-1.txt, 8846-2.txt, 8846-3.txt I was going through the code changes that were needed for getting an application that was running with hbase-0.92 run with hbase-0.95. TableExistsException's package has changed - hence, needs a code change in the application. Offline discussion with some folks led us to believe that this change can probably be reverted back. -- 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-8846) Revert the package name change for TableExistsException
[ https://issues.apache.org/jira/browse/HBASE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13722993#comment-13722993 ] stack commented on HBASE-8846: -- +1 I went through a bunch and they seem to be all restored to their original positions; i.e. snapshot exceptions under snapshot package, util exceptions under util, etc. Revert the package name change for TableExistsException --- Key: HBASE-8846 URL: https://issues.apache.org/jira/browse/HBASE-8846 Project: HBase Issue Type: Bug Affects Versions: 0.95.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.95.2 Attachments: 8846-1.txt, 8846-2.txt, 8846-3.txt I was going through the code changes that were needed for getting an application that was running with hbase-0.92 run with hbase-0.95. TableExistsException's package has changed - hence, needs a code change in the application. Offline discussion with some folks led us to believe that this change can probably be reverted back. -- 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-9076) Throttle log messages for missing peer cluster
[ https://issues.apache.org/jira/browse/HBASE-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723000#comment-13723000 ] stack commented on HBASE-9076: -- You have a trunk patch [~dsw]? Throttle log messages for missing peer cluster -- Key: HBASE-9076 URL: https://issues.apache.org/jira/browse/HBASE-9076 Project: HBase Issue Type: Improvement Components: Replication Affects Versions: 0.95.1, 0.94.10 Reporter: David S. Wang Assignee: David S. Wang Priority: Trivial Attachments: HBASE-9076.patch If the replication peer is not available, then RS logs get flooded by messages similar to the following: 2013-07-19 11:55:27,964 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,670 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,966 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,672 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,969 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer It would be better to change the log level to DEBUG in order to avoid these messages showing up in the default case. -- 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-8846) Revert the package name change for TableExistsException
[ https://issues.apache.org/jira/browse/HBASE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723003#comment-13723003 ] stack commented on HBASE-8846: -- [~enis] Generally, I think the exceptions should be in the package that throws them but this issue is about minimizing the changes apps must make to run on 0.95 so my concern was whether we were putting exceptions back into their original locations; on review it seems they are being put back properly. Revert the package name change for TableExistsException --- Key: HBASE-8846 URL: https://issues.apache.org/jira/browse/HBASE-8846 Project: HBase Issue Type: Bug Affects Versions: 0.95.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.95.2 Attachments: 8846-1.txt, 8846-2.txt, 8846-3.txt I was going through the code changes that were needed for getting an application that was running with hbase-0.92 run with hbase-0.95. TableExistsException's package has changed - hence, needs a code change in the application. Offline discussion with some folks led us to believe that this change can probably be reverted back. -- 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-8846) Revert the package name change for TableExistsException
[ https://issues.apache.org/jira/browse/HBASE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723011#comment-13723011 ] Enis Soztutar commented on HBASE-8846: -- Ok, cool. We should consider doing a follow up issue for re-thinking some of the exception packages as my previous comment. We can then do this with deprecation to have minimal impact. Revert the package name change for TableExistsException --- Key: HBASE-8846 URL: https://issues.apache.org/jira/browse/HBASE-8846 Project: HBase Issue Type: Bug Affects Versions: 0.95.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.95.2 Attachments: 8846-1.txt, 8846-2.txt, 8846-3.txt I was going through the code changes that were needed for getting an application that was running with hbase-0.92 run with hbase-0.95. TableExistsException's package has changed - hence, needs a code change in the application. Offline discussion with some folks led us to believe that this change can probably be reverted back. -- 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-9077) Make Web ui Fluid width
Elliott Clark created HBASE-9077: Summary: Make Web ui Fluid width Key: HBASE-9077 URL: https://issues.apache.org/jira/browse/HBASE-9077 Project: HBase Issue Type: Improvement Reporter: Elliott Clark Assignee: Elliott Clark Region names and other unusually long strings really make the ui look weird. We should go with a fluid ui width the minimize the breakage. -- 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-9077) Make Web ui Fluid width
[ https://issues.apache.org/jira/browse/HBASE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9077: - Component/s: UI Make Web ui Fluid width --- Key: HBASE-9077 URL: https://issues.apache.org/jira/browse/HBASE-9077 Project: HBase Issue Type: Improvement Components: UI Affects Versions: 0.98.0, 0.95.1 Reporter: Elliott Clark Assignee: Elliott Clark Region names and other unusually long strings really make the ui look weird. We should go with a fluid ui width the minimize the breakage. -- 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-9077) Make Web ui Fluid width
[ https://issues.apache.org/jira/browse/HBASE-9077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9077: - Affects Version/s: 0.98.0 0.95.1 Make Web ui Fluid width --- Key: HBASE-9077 URL: https://issues.apache.org/jira/browse/HBASE-9077 Project: HBase Issue Type: Improvement Affects Versions: 0.98.0, 0.95.1 Reporter: Elliott Clark Assignee: Elliott Clark Region names and other unusually long strings really make the ui look weird. We should go with a fluid ui width the minimize the breakage. -- 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-9076) Throttle log messages for missing peer cluster
[ https://issues.apache.org/jira/browse/HBASE-9076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David S. Wang updated HBASE-9076: - Resolution: Duplicate Status: Resolved (was: Patch Available) Throttle log messages for missing peer cluster -- Key: HBASE-9076 URL: https://issues.apache.org/jira/browse/HBASE-9076 Project: HBase Issue Type: Improvement Components: Replication Affects Versions: 0.95.1, 0.94.10 Reporter: David S. Wang Assignee: David S. Wang Priority: Trivial Attachments: HBASE-9076.patch If the replication peer is not available, then RS logs get flooded by messages similar to the following: 2013-07-19 11:55:27,964 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,670 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:28,966 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,672 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer 2013-07-19 11:55:29,969 INFO org.apache.hadoop.hbase.replication.regionserver.ReplicationSource: Getting 0 rs from peer cluster # Indexer_hbaseIndexer It would be better to change the log level to DEBUG in order to avoid these messages showing up in the default case. -- 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-8846) Revert the package name change for TableExistsException
[ https://issues.apache.org/jira/browse/HBASE-8846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723020#comment-13723020 ] Enis Soztutar commented on HBASE-8846: -- +1 on the patch. Let's get this in. Revert the package name change for TableExistsException --- Key: HBASE-8846 URL: https://issues.apache.org/jira/browse/HBASE-8846 Project: HBase Issue Type: Bug Affects Versions: 0.95.0 Reporter: Devaraj Das Assignee: Devaraj Das Fix For: 0.95.2 Attachments: 8846-1.txt, 8846-2.txt, 8846-3.txt I was going through the code changes that were needed for getting an application that was running with hbase-0.92 run with hbase-0.95. TableExistsException's package has changed - hence, needs a code change in the application. Offline discussion with some folks led us to believe that this change can probably be reverted back. -- 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-9052) Prevent split/merged region from assigning again
[
https://issues.apache.org/jira/browse/HBASE-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723035#comment-13723035
]
Hadoop QA commented on HBASE-9052:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12594754/trunk-9052.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 9 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6512//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6512//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6512//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6512//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6512//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6512//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6512//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6512//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6512//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6512//console
This message is automatically generated.
Prevent split/merged region from assigning again
Key: HBASE-9052
URL: https://issues.apache.org/jira/browse/HBASE-9052
Project: HBase
Issue Type: Bug
Components: Region Assignment
Affects Versions: 0.95.1
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Attachments: trunk-9052.patch
If a region is split/merged, before it's removed from meta, you can still
assign it from the HBase shell. It's better to prevent this from happening.
--
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-9052) Prevent split/merged region from assigning again
[ https://issues.apache.org/jira/browse/HBASE-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723037#comment-13723037 ] Jimmy Xiang commented on HBASE-9052: bq. nit: regionOffline should be renamed setRegionOffline or offlineRegion? Sure, I will change regionOffline/regionOnline to offlineRegion/onlineRegion bq. I see tightening up of allowed states but how are we prevening assign of MERGE and SPLIT? That's prevented by the AM#assign method already. For regular assignment, it requires the region to be in offline/closed state. For forcing assignment, it requires the region to be in a closing(or pending close), opening(or pending open). Now, since we move the region to SPLIT/MERGE state, they won't be assigned any more unless the state is changed to offline/closed. If master fails over, we lose these states. However, the merged regions are not known the new master any more since they are deleted from meta. So they won't be assigned either. For split region, the isSplit/isOffline flag is used in rebuilding user regions so they won't be picked up either. Prevent split/merged region from assigning again Key: HBASE-9052 URL: https://issues.apache.org/jira/browse/HBASE-9052 Project: HBase Issue Type: Bug Components: Region Assignment Affects Versions: 0.95.1 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Attachments: trunk-9052.patch If a region is split/merged, before it's removed from meta, you can still assign it from the HBase shell. It's better to prevent this from happening. -- 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-9052) Prevent split/merged region from assigning again
[ https://issues.apache.org/jira/browse/HBASE-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723056#comment-13723056 ] stack commented on HBASE-9052: -- +1 Prevent split/merged region from assigning again Key: HBASE-9052 URL: https://issues.apache.org/jira/browse/HBASE-9052 Project: HBase Issue Type: Bug Components: Region Assignment Affects Versions: 0.95.1 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Attachments: trunk-9052.patch If a region is split/merged, before it's removed from meta, you can still assign it from the HBase shell. It's better to prevent this from happening. -- 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-9038) Compaction WALEdit gives NPEs with Replication enabled
[
https://issues.apache.org/jira/browse/HBASE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Daniel Cryans updated HBASE-9038:
--
Attachment: HBASE-9038.patch
Patch with a refactoring in {{Replication}} to be able to test the filtering,
and a fix to the filtering itself. I also added a unit test.
Compaction WALEdit gives NPEs with Replication enabled
--
Key: HBASE-9038
URL: https://issues.apache.org/jira/browse/HBASE-9038
Project: HBase
Issue Type: Bug
Affects Versions: 0.95.1
Reporter: Jean-Daniel Cryans
Assignee: Jean-Daniel Cryans
Priority: Blocker
Fix For: 0.98.0, 0.95.2
Attachments: HBASE-9038.patch
If you enable replication, and get a compaction requested, you'll see this in
the logs:
{noformat}
2013-07-24 15:16:38,831 ERROR
[regionserver60020-smallCompactions-1374704194254]
regionserver.CompactSplitThread: Compaction failed Request =
regionName=TestTable,057204,1374704192994.6bb7c58d1e6cc99fbfe04592e44fbc35.,
storeName=info, fileCount=4, fileSize=335.1m (115.4m, 115.4m, 69.0m, 35.2m),
priority=6, time=1374704194257521000
java.lang.NullPointerException
at
org.apache.hadoop.hbase.replication.regionserver.Replication.visitLogEntryBeforeWrite(Replication.java:215)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog.doWrite(FSHLog.java:1204)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog.append(FSHLog.java:890)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog.append(FSHLog.java:840)
at
org.apache.hadoop.hbase.regionserver.wal.HLogUtil.writeCompactionMarker(HLogUtil.java:262)
at
org.apache.hadoop.hbase.regionserver.HStore.writeCompactionWalRecord(HStore.java:1026)
at org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:973)
at
org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:1278)
at
org.apache.hadoop.hbase.regionserver.CompactSplitThread$CompactionRunner.run(CompactSplitThread.java:465)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
{noformat}
It's a simple case of filtering METAFAMILY like this:
bq. if (kv.matchingFamily(WALEdit.METAFAMILY)) continue;
and add a unit test.
--
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-9038) Compaction WALEdit gives NPEs with Replication enabled
[
https://issues.apache.org/jira/browse/HBASE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Daniel Cryans updated HBASE-9038:
--
Status: Patch Available (was: Open)
Compaction WALEdit gives NPEs with Replication enabled
--
Key: HBASE-9038
URL: https://issues.apache.org/jira/browse/HBASE-9038
Project: HBase
Issue Type: Bug
Affects Versions: 0.95.1
Reporter: Jean-Daniel Cryans
Assignee: Jean-Daniel Cryans
Priority: Blocker
Fix For: 0.98.0, 0.95.2
Attachments: HBASE-9038.patch
If you enable replication, and get a compaction requested, you'll see this in
the logs:
{noformat}
2013-07-24 15:16:38,831 ERROR
[regionserver60020-smallCompactions-1374704194254]
regionserver.CompactSplitThread: Compaction failed Request =
regionName=TestTable,057204,1374704192994.6bb7c58d1e6cc99fbfe04592e44fbc35.,
storeName=info, fileCount=4, fileSize=335.1m (115.4m, 115.4m, 69.0m, 35.2m),
priority=6, time=1374704194257521000
java.lang.NullPointerException
at
org.apache.hadoop.hbase.replication.regionserver.Replication.visitLogEntryBeforeWrite(Replication.java:215)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog.doWrite(FSHLog.java:1204)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog.append(FSHLog.java:890)
at
org.apache.hadoop.hbase.regionserver.wal.FSHLog.append(FSHLog.java:840)
at
org.apache.hadoop.hbase.regionserver.wal.HLogUtil.writeCompactionMarker(HLogUtil.java:262)
at
org.apache.hadoop.hbase.regionserver.HStore.writeCompactionWalRecord(HStore.java:1026)
at org.apache.hadoop.hbase.regionserver.HStore.compact(HStore.java:973)
at
org.apache.hadoop.hbase.regionserver.HRegion.compact(HRegion.java:1278)
at
org.apache.hadoop.hbase.regionserver.CompactSplitThread$CompactionRunner.run(CompactSplitThread.java:465)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
{noformat}
It's a simple case of filtering METAFAMILY like this:
bq. if (kv.matchingFamily(WALEdit.METAFAMILY)) continue;
and add a unit test.
--
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-9052) Prevent split/merged region from assigning again
[ https://issues.apache.org/jira/browse/HBASE-9052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723097#comment-13723097 ] Jimmy Xiang commented on HBASE-9052: regionOffline/regionOnline is already used in many places, even in the access control coprocessor. Probably we will leave the naming like this? Prevent split/merged region from assigning again Key: HBASE-9052 URL: https://issues.apache.org/jira/browse/HBASE-9052 Project: HBase Issue Type: Bug Components: Region Assignment Affects Versions: 0.95.1 Reporter: Jimmy Xiang Assignee: Jimmy Xiang Attachments: trunk-9052.patch If a region is split/merged, before it's removed from meta, you can still assign it from the HBase shell. It's better to prevent this from happening. -- 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-9078) Downstream build including hbase-client fails because can't find com.sun.jdmk:jmxtools
stack created HBASE-9078:
Summary: Downstream build including hbase-client fails because
can't find com.sun.jdmk:jmxtools
Key: HBASE-9078
URL: https://issues.apache.org/jira/browse/HBASE-9078
Project: HBase
Issue Type: Sub-task
Reporter: stack
Assignee: stack
Fix For: 0.95.2
I've hacked up a downstream maven project. If I include hbase-client, my build
fails with this:
{code}
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.821s
[INFO] Finished at: Mon Jul 29 15:58:39 PDT 2013
[INFO] Final Memory: 4M/81M
[INFO]
[ERROR] Failed to execute goal on project client: Could not resolve
dependencies for project org.hbase.downstream:client:jar:1.0-SNAPSHOT: The
following artifacts could not be resolved: com.sun.jdmk:jmxtools:jar:1.2.1,
com.sun.jmx:jmxri:jar:1.2.1: Failure to find com.sun.jdmk:jmxtools:jar:1.2.1 in
http://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
on project client: Could not resolve dependencies for project
org.hbase.downstream:client:jar:1.0-SNAPSHOT: The following artifacts could not
be resolved: com.sun.jdmk:jmxtools:jar:1.2.1, com.sun.jmx:jmxri:jar:1.2.1:
Failure to find com.sun.jdmk:jmxtools:jar:1.2.1 in
http://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
{code}
Digging, the 1.2.15 log4j pulled in by our transitive zk include has bad
metadata -- see
http://stackoverflow.com/questions/9047949/missing-artifact-com-sun-jdmkjmxtoolsjar1-2-1
--
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-9074) TestAdmin.testMoveToPreviouslyAssignedRS fails
[
https://issues.apache.org/jira/browse/HBASE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13723106#comment-13723106
]
Hadoop QA commented on HBASE-9074:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12594780/trunk-9074_v2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6513//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6513//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6513//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6513//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6513//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6513//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6513//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6513//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6513//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6513//console
This message is automatically generated.
TestAdmin.testMoveToPreviouslyAssignedRS fails
--
Key: HBASE-9074
URL: https://issues.apache.org/jira/browse/HBASE-9074
Project: HBase
Issue Type: Test
Components: test
Affects Versions: 0.98.0, 0.95.2
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Minor
Attachments: trunk-9074.patch, trunk-9074_v2.patch
http://54.241.6.143/job/HBase-0.95/org.apache.hbase$hbase-server/716/testReport/org.apache.hadoop.hbase.client/TestAdmin/testMoveToPreviouslyAssignedRS/
{noformat}
java.lang.NullPointerException
at
org.apache.hadoop.hbase.client.TestAdmin.testMoveToPreviouslyAssignedRS(TestAdmin.java:1567)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at
[jira] [Updated] (HBASE-9078) Downstream build including hbase-client fails because can't find com.sun.jdmk:jmxtools
[
https://issues.apache.org/jira/browse/HBASE-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-9078:
-
Attachment: jdmk.txt
Small patch to exclude what zk pulls in. Before this patch, zk was pulling in:
{code}
[DEBUG] org.apache.zookeeper:zookeeper:jar:3.4.5:compile
[DEBUG] log4j:log4j:jar:1.2.15:compile
[DEBUG] javax.mail:mail:jar:1.4:compile
[DEBUG]javax.activation:activation:jar:1.1:compile
[DEBUG] javax.jms:jms:jar:1.1:compile
[DEBUG] com.sun.jdmk:jmxtools:jar:1.2.1:compile
[DEBUG] com.sun.jmx:jmxri:jar:1.2.1:compile
{code}
After the patch, we pull in:
{code}
[DEBUG] org.apache.zookeeper:zookeeper:jar:3.4.5:compile
[DEBUG] log4j:log4j:jar:1.2.15:compile
[DEBUG] javax.mail:mail:jar:1.4:compile
[DEBUG]javax.activation:activation:jar:1.1:compile
{code}
... which is probably still too much but will leave it for now.
Downstream build including hbase-client fails because can't find
com.sun.jdmk:jmxtools
--
Key: HBASE-9078
URL: https://issues.apache.org/jira/browse/HBASE-9078
Project: HBase
Issue Type: Sub-task
Components: build
Reporter: stack
Assignee: stack
Fix For: 0.95.2
Attachments: jdmk.txt
I've hacked up a downstream maven project. If I include hbase-client, my
build fails with this:
{code}
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.821s
[INFO] Finished at: Mon Jul 29 15:58:39 PDT 2013
[INFO] Final Memory: 4M/81M
[INFO]
[ERROR] Failed to execute goal on project client: Could not resolve
dependencies for project org.hbase.downstream:client:jar:1.0-SNAPSHOT: The
following artifacts could not be resolved: com.sun.jdmk:jmxtools:jar:1.2.1,
com.sun.jmx:jmxri:jar:1.2.1: Failure to find com.sun.jdmk:jmxtools:jar:1.2.1
in http://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal on project client: Could not resolve dependencies for project
org.hbase.downstream:client:jar:1.0-SNAPSHOT: The following artifacts could
not be resolved: com.sun.jdmk:jmxtools:jar:1.2.1,
com.sun.jmx:jmxri:jar:1.2.1: Failure to find com.sun.jdmk:jmxtools:jar:1.2.1
in http://repo.maven.apache.org/maven2 was cached in the local repository,
resolution will not be reattempted until the update interval of central has
elapsed or updates are forced
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
{code}
Digging, the 1.2.15 log4j pulled in by our transitive zk include has bad
metadata -- see
http://stackoverflow.com/questions/9047949/missing-artifact-com-sun-jdmkjmxtoolsjar1-2-1
--
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-7826) Improve Hbase Thrift v1 to return results in sorted order
[ https://issues.apache.org/jira/browse/HBASE-7826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Daniel Cryans updated HBASE-7826: -- Attachment: HBASE-7826-0.94-v7.patch Patch for 0.94 that has the unit test and the line fixes. I'm now going to commit this. Improve Hbase Thrift v1 to return results in sorted order - Key: HBASE-7826 URL: https://issues.apache.org/jira/browse/HBASE-7826 Project: HBase Issue Type: New Feature Components: Thrift Affects Versions: 0.94.0 Reporter: Shivendra Pratap Singh Assignee: Shivendra Pratap Singh Priority: Minor Labels: Hbase, Thrift Attachments: 7826-v6.patch, HBASE-7826-0.94-v7.patch, hbase_7826.patch, hbase_7826.patch, HBASE-7826.patch, hbase_7826_sortcolumnFlag.1.patch, hbase_7826_sortcolumnFlag.2.patch, hbase_7826_sortcolumnFlag.3.patch, hbase_7826_sortcolumnFlag.4.patch, hbase_7826_sortcolumnFlag.5.patch, hbase_7826_sortcolumnFlag.patch, hbase_7826_trunk.patch Hbase natively stores columns sorted based on the column qualifier. A scan is guaranteed to return sorted columns. The Java API works fine but the Thrift API is broken. Hbase uses TreeMap that ensures that sort order is maintained. However Hbase thrift specification uses a simple Map to store the data. A map, since it is unordered doesn't result in columns being returned in a sort order that is consistent with their storage in Hbase. -- 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
