[jira] [Updated] (HBASE-10411) [Book] Add a kerberos 'request is a replay (34)' issue at troubleshooting section

2014-02-05 Thread takeshi.miao (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

takeshi.miao updated HBASE-10411:
-

Attachment: HBASE-10411-trunk-v01.patch

added a patch

 [Book] Add a kerberos 'request is a replay (34)' issue at troubleshooting 
 section
 -

 Key: HBASE-10411
 URL: https://issues.apache.org/jira/browse/HBASE-10411
 Project: HBase
  Issue Type: Improvement
  Components: documentation, security
Reporter: takeshi.miao
Assignee: takeshi.miao
Priority: Minor
 Attachments: HBASE-10411-trunk-v01.patch, HBASE-10411-v01.odt


 For kerberos 'request is a replay (34)' issue (HBASE-10379), adding it to the 
 troubleshooting section in HBase book



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10411) [Book] Add a kerberos 'request is a replay (34)' issue at troubleshooting section

2014-02-05 Thread takeshi.miao (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

takeshi.miao updated HBASE-10411:
-

Status: Patch Available  (was: Open)

 [Book] Add a kerberos 'request is a replay (34)' issue at troubleshooting 
 section
 -

 Key: HBASE-10411
 URL: https://issues.apache.org/jira/browse/HBASE-10411
 Project: HBase
  Issue Type: Improvement
  Components: documentation, security
Reporter: takeshi.miao
Assignee: takeshi.miao
Priority: Minor
 Attachments: HBASE-10411-trunk-v01.patch, HBASE-10411-v01.odt


 For kerberos 'request is a replay (34)' issue (HBASE-10379), adding it to the 
 troubleshooting section in HBase book



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10411) [Book] Add a kerberos 'request is a replay (34)' issue at troubleshooting section

2014-02-05 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891964#comment-13891964
 ] 

Hadoop QA commented on HBASE-10411:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12627091/HBASE-10411-trunk-v01.patch
  against trunk revision .
  ATTACHMENT ID: 12627091

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+0 tests included{color}.  The patch appears to be a 
documentation patch that doesn't require tests.

{color:green}+1 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{color:green}+1 hadoop1.1{color}.  The patch compiles against the hadoop 
1.1 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:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+titleSecure Client Connect ([Caused by GSSException: No 
valid credentials provided (Mechanism level: Request is a replay (34) V 
PROCESS_TGS)])/title
+This issue is caused by the Kerberos bugs for its replay_cache component, 
link 
xlink:href=http://krbdev.mit.edu/rt/Ticket/Display.html?id=1201;#1201/link 
and link 
xlink:href=http://krbdev.mit.edu/rt/Ticket/Display.html?id=5924;#5924/link, 
whom were talking about that the old version of krb5-server would 
false-positively blocks subsequent requests sent from a Principal.
+In this case, which means that the krb5-server would sometimes block the 
connections sent from one Client (one HTable instance with multi-threading 
connection instances for each regionserver); You would see such message 
'Request is a replay (34)' in your client log if you hit this bug. You can just 
ignore this message due to the implementation of HTable will retry 5 * 10 for 
each failed connection by default. The HTable will throw IOException if any 
connection to regionserver was failed after the retries, therefore, the user 
client code for HTable instance still can handle it further.
+Otherwise, you can pick a new version of krb5-server to solve this issue 
gracefully. We tested and  mitigated this issue in the environment: 
hbase-0.94.16 with krb5-server-1.10.3 on RHEL-6.4_GA-x86_64-10-Hourly2 on AWS, 
compared to the old environment: HBase-0.94.16 with krb5-server-1.6.1 on 
CentOS-5.3. Please refer to JIRA link 
xlink:href=https://issues.apache.org/jira/browse/HBASE-10379;HBASE-10379/link
 for more details.

  {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/8603//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8603//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8603//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8603//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8603//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8603//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8603//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8603//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8603//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8603//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8603//console

This message is automatically generated.

 [Book] Add a kerberos 'request is a replay (34)' issue at troubleshooting 
 section
 -

 Key: HBASE-10411
 URL: https://issues.apache.org/jira/browse/HBASE-10411
   

[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13891966#comment-13891966
 ] 

Hudson commented on HBASE-10467:


FAILURE: Integrated in HBase-TRUNK #4887 (See 
[https://builds.apache.org/job/HBase-TRUNK/4887/])
HBASE-10467 Revert from trunk (tedyu: rev 1564640)
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestDurability.java


 Restore HTableDescriptor#isDeferredLogFlush()
 -

 Key: HBASE-10467
 URL: https://issues.apache.org/jira/browse/HBASE-10467
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0

 Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt


 HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked 
 Deprecated.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Jean-Marc Spaggiari (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892025#comment-13892025
 ] 

Jean-Marc Spaggiari commented on HBASE-10469:
-

Hi Vivek,

Are you going to provide a patch for this?

JM

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor

 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread Nicolas Liochon (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892079#comment-13892079
 ] 

Nicolas Liochon commented on HBASE-10337:
-

The release warning is about the license in one of the new files. I can add 
this on commit. Any +1 around? 
I would like to commit this on .98  .99. It does not solve all interruption 
issues, but it's a step forward already.

 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Vivek Ganesan (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892086#comment-13892086
 ] 

Vivek Ganesan commented on HBASE-10469:
---

Hi Jean,

Can you please provide me write access to this books page?  I will update it to 
point to the right url?

Thank you.

Regards,
Vivek Ganesan

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor

 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Jean-Marc Spaggiari (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892104#comment-13892104
 ] 

Jean-Marc Spaggiari commented on HBASE-10469:
-

Hi Vivek,

this is not the way it works ;) We can not just give you write access.

I will guide you through the steps.

You will need to create and update a patch (see 
http://hbase.apache.org/book/submitting.patches.html ).

For that, you will need to retrieve the SVN trunk branch locally ( 
http://hbase.apache.org/source-repository.html ), do the modification in the 
documentation ( src/main/docbkx/book.xml ), create a patch (diff) and upload it 
to this JIRA.

Upon approval, one commiter will be able to apply your modification the book.

Just ping us here if there is any of those steps causing you difficulties.

JM

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor

 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Vivek Ganesan (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892108#comment-13892108
 ] 

Vivek Ganesan commented on HBASE-10469:
---

I am onto it right now :) Can you please assign this JIRA to me?  I will submit 
the patch in JIRA.

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor

 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Jean-Marc Spaggiari (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892117#comment-13892117
 ] 

Jean-Marc Spaggiari commented on HBASE-10469:
-

Hi Vivek,

I can assign his JIRA to you, but you should also be able to assign it to 
yourself. On the top right corner of the JIRA page, do you have an Assign to 
me link? If so, just click on it. Else, you should have an Assign button on 
the middle of the top of the page.

Last, if you still don't have, I will do it or you ;)

JM

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor

 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Vivek Ganesan (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892121#comment-13892121
 ] 

Vivek Ganesan commented on HBASE-10469:
---

Looks like I dont have contributor access to Hbase project.  Could you please 
assign it to me?

Thanks,
Vivek Ganesan

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor

 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Jean-Marc Spaggiari (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892140#comment-13892140
 ] 

Jean-Marc Spaggiari commented on HBASE-10469:
-

Hum. I don't see you account in the list. I search using Vivek, using Ganesan, 
nothing.

Have you created your account recently?

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor

 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Vivek Ganesan (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892142#comment-13892142
 ] 

Vivek Ganesan commented on HBASE-10469:
---

No,  I have been in Apache JIRA for a while.  My user id is vivganes.  I have 
contributed to hdfs project previously

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor

 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Jonathan Hsieh (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892154#comment-13892154
 ] 

Jonathan Hsieh commented on HBASE-10469:


Hi [~vivganes], we'll add you as a contributor to hbase (so we an assign 
credit) when we commit your first patch to hbase. 

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor

 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Jean-Marc Spaggiari (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892267#comment-13892267
 ] 

Jean-Marc Spaggiari commented on HBASE-10469:
-

Thanks Vivek. Patch looks good to me.

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor
 Attachments: HBASE-10469.patch


 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892268#comment-13892268
 ] 

stack commented on HBASE-10337:
---

This looks like a safe nice improvement.  The IE is not added to a public API 
though?   That is intentional?  +1

 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Vivek Ganesan (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vivek Ganesan updated HBASE-10469:
--

Attachment: HBASE-10469.patch

Patch to fix broken link

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor
 Attachments: HBASE-10469.patch


 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Vivek Ganesan (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vivek Ganesan updated HBASE-10469:
--

Attachment: HBASE-10469.patch

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor
 Attachments: HBASE-10469.patch


 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Vivek Ganesan (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vivek Ganesan updated HBASE-10469:
--

Attachment: (was: HBASE-10469.patch)

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor
 Attachments: HBASE-10469.patch


 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread Nicolas Liochon (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892276#comment-13892276
 ] 

Nicolas Liochon commented on HBASE-10337:
-

bq. The IE is not added to a public API though?
Yeah, it's always hidden behind the IOException. The JDK (1.7 at least) does 
like this: the exception is never declared explicitly. This seems to be the 
most common pattern, even if it's questionable...

 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Resolved] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Jonathan Hsieh (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hsieh resolved HBASE-10469.


  Resolution: Fixed
Hadoop Flags: Reviewed

Thanks for review jms, and thanks for patch vivek.  commited.  Will go live 
next time we push the website.

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Priority: Minor
 Attachments: HBASE-10469.patch


 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Jonathan Hsieh (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Hsieh updated HBASE-10469:
---

  Component/s: documentation
Fix Version/s: 0.99.0
 Assignee: Vivek Ganesan

 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
  Components: documentation
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Assignee: Vivek Ganesan
Priority: Minor
 Fix For: 0.99.0

 Attachments: HBASE-10469.patch


 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10347) HRegionInfo changes for adding replicaId and MetaEditor/MetaReader changes for region replicas

2014-02-05 Thread Enis Soztutar (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Enis Soztutar updated HBASE-10347:
--

Attachment: hbase-10347_redo_v7.patch

Updated patch to fix the NPE from TestAssignmentManager. 

 HRegionInfo changes for adding replicaId and MetaEditor/MetaReader changes 
 for region replicas
 --

 Key: HBASE-10347
 URL: https://issues.apache.org/jira/browse/HBASE-10347
 Project: HBase
  Issue Type: Sub-task
  Components: Region Assignment
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.99.0

 Attachments: hbase-10347_redo_v4.patch, hbase-10347_redo_v5.patch, 
 hbase-10347_redo_v6.patch, hbase-10347_redo_v7.patch


 As per parent jira, the cleanest way to add region replicas we think is to 
 actually create one more region per replica per primary region. So for 
 example, if a table has 10 regions with replication = 3, the table would 
 indeed be created with 30 regions. These regions will be handled and assigned 
 individually for AM purposes. 
 We can add replicaId to HRegionInfo to indicate the replicaId, and use this 
 to differentiate different replicas of the same region. So, primary replica 
 would have replicaId = 0, and the others will have replicaId  0. 
 These replicas will share the same regionId prefix, but differ in an appended 
 replicaId. The primary will not contain the replicaId so that no changes 
 would be needed for existing tables. 
 In meta, the replica regions are kept in the same row as the primary ( so for 
 above example, there will be 10 rows in meta). The servers for the replicas 
 are kept in columns like server+replicaId. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10347) HRegionInfo changes for adding replicaId and MetaEditor/MetaReader changes for region replicas

2014-02-05 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892343#comment-13892343
 ] 

Hadoop QA commented on HBASE-10347:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12627159/hbase-10347_redo_v7.patch
  against trunk revision .
  ATTACHMENT ID: 12627159

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 17 new 
or modified tests.

{color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8604//console

This message is automatically generated.

 HRegionInfo changes for adding replicaId and MetaEditor/MetaReader changes 
 for region replicas
 --

 Key: HBASE-10347
 URL: https://issues.apache.org/jira/browse/HBASE-10347
 Project: HBase
  Issue Type: Sub-task
  Components: Region Assignment
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.99.0

 Attachments: hbase-10347_redo_v4.patch, hbase-10347_redo_v5.patch, 
 hbase-10347_redo_v6.patch, hbase-10347_redo_v7.patch


 As per parent jira, the cleanest way to add region replicas we think is to 
 actually create one more region per replica per primary region. So for 
 example, if a table has 10 regions with replication = 3, the table would 
 indeed be created with 30 regions. These regions will be handled and assigned 
 individually for AM purposes. 
 We can add replicaId to HRegionInfo to indicate the replicaId, and use this 
 to differentiate different replicas of the same region. So, primary replica 
 would have replicaId = 0, and the others will have replicaId  0. 
 These replicas will share the same regionId prefix, but differ in an appended 
 replicaId. The primary will not contain the replicaId so that no changes 
 would be needed for existing tables. 
 In meta, the replica regions are kept in the same row as the primary ( so for 
 above example, there will be 10 rows in meta). The servers for the replicas 
 are kept in columns like server+replicaId. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread Andrew Purtell (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892353#comment-13892353
 ] 

Andrew Purtell commented on HBASE-10337:


I'm about to tag the next RC, will commit this shortly.

 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread Andrew Purtell (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892369#comment-13892369
 ] 

Andrew Purtell commented on HBASE-10337:


Committed to trunk and 0.98. New test passes locally. Should I resolve this 
issue now?

 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread Nicolas Liochon (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892373#comment-13892373
 ] 

Nicolas Liochon commented on HBASE-10337:
-

I can do that ;-).
I will create other jiras for the remaining issues. As written, the test should 
not be flaky (ping me if necessary), but I know that it does not cover all 
cases.

Thanks a lot Andrew.

 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread Nicolas Liochon (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Liochon updated HBASE-10337:


  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10466) Wrong calculation of total memstore size in HRegion which could cause data loss

2014-02-05 Thread Yunfan Zhong (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yunfan Zhong updated HBASE-10466:
-

Description: 
When there are failed flushes, data to be flush are kept in each MemStore's 
snapshot. Next flush attempt will continue on snapshot first. However, the 
counter of total memstore size in HRegion is always deduced by the sum of 
current memstore sizes after the flush succeeds. This calculation is definitely 
wrong if flush fails last time.
When the region is closing, there are two flushes. During the period that some 
data is in snapshot and the memstore size is incorrect, the first flush 
successfully saved data in snapshot. But the memstore size counter was reduced 
to 0 or even less. This prevented the second flush since 
HRegion.internalFlushcache() directly returns while total memstore size is not 
greater than 0. As result, data in memstores were lost.
It could cause mass data loss up to the size limit of memstores.

  was:
When there are failed flushes, data to be flush are kept in each MemStore's 
snapshot. Next flush attempt will continue on snapshot first. However, the 
counter of total memstore size in HRegion is always deduced by the sum of 
current memstore sizes after the flush succeeds. This calculation is definitely 
wrong if flush fails last time.
When the server is shutting down, there are two flushes. During the missing KV 
issue period, the first flush successfully saved data in snapshot. But the size 
counter was reduced to 0 or even less. This prevented the second flush since 
HRegion.internalFlushcache() directly returns while total memstore size is not 
greater than 0. As result, data in memstores were lost.
It could cause mass data loss up to the size limit of each memstore. For 
example, a region had 516.3M data (size limit is 516M) in memstore at the 
moment because of failing flushes for more than one hour. After the region was 
closed, these KVs were missing from HFiles but exist in HLog.


 Wrong calculation of total memstore size in HRegion which could cause data 
 loss
 ---

 Key: HBASE-10466
 URL: https://issues.apache.org/jira/browse/HBASE-10466
 Project: HBase
  Issue Type: Bug
  Components: regionserver
Affects Versions: 0.89-fb
Reporter: Yunfan Zhong
Priority: Critical
 Fix For: 0.89-fb


 When there are failed flushes, data to be flush are kept in each MemStore's 
 snapshot. Next flush attempt will continue on snapshot first. However, the 
 counter of total memstore size in HRegion is always deduced by the sum of 
 current memstore sizes after the flush succeeds. This calculation is 
 definitely wrong if flush fails last time.
 When the region is closing, there are two flushes. During the period that 
 some data is in snapshot and the memstore size is incorrect, the first flush 
 successfully saved data in snapshot. But the memstore size counter was 
 reduced to 0 or even less. This prevented the second flush since 
 HRegion.internalFlushcache() directly returns while total memstore size is 
 not greater than 0. As result, data in memstores were lost.
 It could cause mass data loss up to the size limit of memstores.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-10337:
---

Attachment: 10337-addendum.patch

Committed 10337-addendum.patch to trunk and 0.98 which adds missing license 
headers. Apologies for missing that one the first go around.

 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337-addendum.patch, 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10465) TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes

2014-02-05 Thread Jimmy Xiang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892427#comment-13892427
 ] 

Jimmy Xiang commented on HBASE-10465:
-

Yes, increased the sleep time to 1000ms.  Thanks.

 TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
 ---

 Key: HBASE-10465
 URL: https://issues.apache.org/jira/browse/HBASE-10465
 Project: HBase
  Issue Type: Test
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.99.0

 Attachments: hbase-10465.patch


 It looks like sleeping 100 ms is not enough for the permission change to 
 propagate to other watchers. Will increase the sleeping time a little.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10465) TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes

2014-02-05 Thread Jimmy Xiang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jimmy Xiang updated HBASE-10465:


   Resolution: Fixed
Fix Version/s: 0.99.0
 Hadoop Flags: Reviewed
   Status: Resolved  (was: Patch Available)

 TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
 ---

 Key: HBASE-10465
 URL: https://issues.apache.org/jira/browse/HBASE-10465
 Project: HBase
  Issue Type: Test
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.99.0

 Attachments: hbase-10465.patch


 It looks like sleeping 100 ms is not enough for the permission change to 
 propagate to other watchers. Will increase the sleeping time a little.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (HBASE-10470) Import generating huge log file while importing large amounts of data

2014-02-05 Thread Vasu Mariyala (JIRA)
Vasu Mariyala created HBASE-10470:
-

 Summary: Import generating huge log file while importing large 
amounts of data
 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Attachments: 0.94-HBASE-10470.patch

Import mapper has System.out.println statements for each key value if there is 
filter associated with the import. This is generating huge log file while 
importing large amounts of data. These statements must be changed to trace and 
log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10470) Import generating huge log file while importing large amounts of data

2014-02-05 Thread Vasu Mariyala (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vasu Mariyala updated HBASE-10470:
--

Attachment: 0.94-HBASE-10470.patch

 Import generating huge log file while importing large amounts of data
 -

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Attachments: 0.94-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10470) Import generating huge log file while importing large amounts of data

2014-02-05 Thread Vasu Mariyala (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vasu Mariyala updated HBASE-10470:
--

Attachment: trunk-HBASE-10470.patch

 Import generating huge log file while importing large amounts of data
 -

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10470) Import generating huge log file while importing large amounts of data

2014-02-05 Thread Vasu Mariyala (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vasu Mariyala updated HBASE-10470:
--

Status: Patch Available  (was: Open)

 Import generating huge log file while importing large amounts of data
 -

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10469) Hbase book client.html has a broken link

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892456#comment-13892456
 ] 

Hudson commented on HBASE-10469:


SUCCESS: Integrated in HBase-TRUNK #4888 (See 
[https://builds.apache.org/job/HBase-TRUNK/4888/])
HBASE-10469 HBase book client.html has a broken link (Vivek Ganesan) (jmhsieh: 
rev 1564826)
* /hbase/trunk/src/main/docbkx/book.xml


 Hbase book client.html has a broken link
 

 Key: HBASE-10469
 URL: https://issues.apache.org/jira/browse/HBASE-10469
 Project: HBase
  Issue Type: Bug
  Components: documentation
 Environment: URL : http://hbase.apache.org/book/client.html
Reporter: Vivek Ganesan
Assignee: Vivek Ganesan
Priority: Minor
 Fix For: 0.99.0

 Attachments: HBASE-10469.patch


 In section 9.3.2 - WriteBuffer and Batch Methods, the link  ACID semantics  
 is broken.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generating huge log file while importing large amounts of data

2014-02-05 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892459#comment-13892459
 ] 

Ted Yu commented on HBASE-10470:


+1

 Import generating huge log file while importing large amounts of data
 -

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10470) Import generating huge log file while importing large amounts of data

2014-02-05 Thread Lars Hofhansl (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl updated HBASE-10470:
--

Fix Version/s: 0.94.17
   0.99.0
   0.96.2
   0.98.0

 Import generating huge log file while importing large amounts of data
 -

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generating huge log file while importing large amounts of data

2014-02-05 Thread Lars Hofhansl (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892469#comment-13892469
 ] 

Lars Hofhansl commented on HBASE-10470:
---

[~apurtell], if you haven't rolled the RC, yet, might as well pull it in. 
Agreed?

 Import generating huge log file while importing large amounts of data
 -

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generating huge log file while importing large amounts of data

2014-02-05 Thread Lars Hofhansl (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892466#comment-13892466
 ] 

Lars Hofhansl commented on HBASE-10470:
---

+1
(as discussed offline, this is terrible)

 Import generating huge log file while importing large amounts of data
 -

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()

2014-02-05 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892470#comment-13892470
 ] 

Enis Soztutar commented on HBASE-10467:
---

bq. So when we make some API deprecated in one version, when we can remove 
this? I was thinking that we can remove it in next major version. I am also 
having the same feeling as what Lars said above. Pls correct if I am wrong.
We had deprecated stuff removed from 0.98, but we decided to add some of them 
back so that some important clients (like Pig and Hive) does not have to have a 
shim layer to be able to compile both with 0.94, 0.96 and 0.98. It is a 
convenience we are providing for the downstreamers to make their life easier I 
think. See HBASE-10368 and HBASE-10339. The main argument is that, as long as 
0.94 is around, downstreamers will want to be able to compile with 0.94 and 
0.96,0.98, and 1.0 at the same time. I am fine with dropping the API's in 1.0, 
as long as we are not causing a lot of disruption to our consumers. 

bq. Reverted patch v3 from trunk.
HTD.isDeferredLogFlush() was replaced with setDurability(), and the method was 
deprecated. We should remove the new methods isAsyncLogFlush() altogether.  

 Restore HTableDescriptor#isDeferredLogFlush()
 -

 Key: HBASE-10467
 URL: https://issues.apache.org/jira/browse/HBASE-10467
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0

 Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt


 HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked 
 Deprecated.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generating huge log file while importing large amounts of data

2014-02-05 Thread Andrew Purtell (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892473#comment-13892473
 ] 

Andrew Purtell commented on HBASE-10470:


+1

I was working on a RC earlier but am now waiting for a security fix to show up 
later today.

 Import generating huge log file while importing large amounts of data
 -

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()

2014-02-05 Thread Andrew Purtell (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892478#comment-13892478
 ] 

Andrew Purtell commented on HBASE-10467:


What is going on with this issue? Is it actually complete? I wish the code 
churn here with commits and reverts could have been avoided.

 Restore HTableDescriptor#isDeferredLogFlush()
 -

 Key: HBASE-10467
 URL: https://issues.apache.org/jira/browse/HBASE-10467
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0

 Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt


 HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked 
 Deprecated.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()

2014-02-05 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892480#comment-13892480
 ] 

Ted Yu commented on HBASE-10467:


This issue is complete.

Removal of isAsyncLogFlush() in trunk can be done in another JIRA.

 Restore HTableDescriptor#isDeferredLogFlush()
 -

 Key: HBASE-10467
 URL: https://issues.apache.org/jira/browse/HBASE-10467
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0

 Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt


 HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked 
 Deprecated.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()

2014-02-05 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892483#comment-13892483
 ] 

Enis Soztutar commented on HBASE-10467:
---

Sorry for the clutter. The changes should be done for 0.98. We are discussing 
the removing these methods from trunk. I guess it makes more sense to do that 
in a new issue. Let me open it. 

 Restore HTableDescriptor#isDeferredLogFlush()
 -

 Key: HBASE-10467
 URL: https://issues.apache.org/jira/browse/HBASE-10467
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0

 Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt


 HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked 
 Deprecated.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()

2014-02-05 Thread Andrew Purtell (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892485#comment-13892485
 ] 

Andrew Purtell commented on HBASE-10467:


Ok, great, thanks for the clarifications.

 Restore HTableDescriptor#isDeferredLogFlush()
 -

 Key: HBASE-10467
 URL: https://issues.apache.org/jira/browse/HBASE-10467
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0

 Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt


 HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked 
 Deprecated.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (HBASE-10471) Remove HTD.isAsyncLogFlush() from trunk

2014-02-05 Thread Enis Soztutar (JIRA)
Enis Soztutar created HBASE-10471:
-

 Summary: Remove HTD.isAsyncLogFlush() from trunk
 Key: HBASE-10471
 URL: https://issues.apache.org/jira/browse/HBASE-10471
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.99.0


See HBASE-10467 for discussion. We renamed a deprecated method, which we should 
have removed instead. 

We will keep the deprecated method in 0.98 (via HBASE-10467) and remove it from 
trunk. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()

2014-02-05 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892487#comment-13892487
 ] 

Enis Soztutar commented on HBASE-10467:
---

See HBASE-10471

 Restore HTableDescriptor#isDeferredLogFlush()
 -

 Key: HBASE-10467
 URL: https://issues.apache.org/jira/browse/HBASE-10467
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0

 Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt


 HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked 
 Deprecated.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (HBASE-10472) Manage the interruption in ZKUtil#getData

2014-02-05 Thread Nicolas Liochon (JIRA)
Nicolas Liochon created HBASE-10472:
---

 Summary: Manage the interruption in ZKUtil#getData
 Key: HBASE-10472
 URL: https://issues.apache.org/jira/browse/HBASE-10472
 Project: HBase
  Issue Type: Bug
  Components: Client, master, regionserver
Affects Versions: 0.98.0, 0.99.0
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
 Fix For: 0.98.1, 0.99.0


Many, but not all, methods in ZKUtil partly hides the interruption: they return 
null or something like that. Many times, this will result in a NPE, or 
something undefined. 

This jira is limited to the getData to keep things small enough (it's used in 
hbase-client code).
The code is supposed to behave at least 'as well as before', or better 
(hopefully).

It could be included in a later .98 release (98.1) and in .99



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10471) Remove HTD.isAsyncLogFlush() from trunk

2014-02-05 Thread Enis Soztutar (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Enis Soztutar updated HBASE-10471:
--

Status: Patch Available  (was: Open)

 Remove HTD.isAsyncLogFlush() from trunk
 ---

 Key: HBASE-10471
 URL: https://issues.apache.org/jira/browse/HBASE-10471
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.99.0

 Attachments: hbase-10471_v1.patch


 See HBASE-10467 for discussion. We renamed a deprecated method, which we 
 should have removed instead. 
 We will keep the deprecated method in 0.98 (via HBASE-10467) and remove it 
 from trunk. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10472) Manage the interruption in ZKUtil#getData

2014-02-05 Thread Nicolas Liochon (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Liochon updated HBASE-10472:


Attachment: 10472.v1.patch

 Manage the interruption in ZKUtil#getData
 -

 Key: HBASE-10472
 URL: https://issues.apache.org/jira/browse/HBASE-10472
 Project: HBase
  Issue Type: Bug
  Components: Client, master, regionserver
Affects Versions: 0.98.0, 0.99.0
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
 Fix For: 0.98.1, 0.99.0

 Attachments: 10472.v1.patch


 Many, but not all, methods in ZKUtil partly hides the interruption: they 
 return null or something like that. Many times, this will result in a NPE, or 
 something undefined. 
 This jira is limited to the getData to keep things small enough (it's used in 
 hbase-client code).
 The code is supposed to behave at least 'as well as before', or better 
 (hopefully).
 It could be included in a later .98 release (98.1) and in .99



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10471) Remove HTD.isAsyncLogFlush() from trunk

2014-02-05 Thread Enis Soztutar (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Enis Soztutar updated HBASE-10471:
--

Attachment: hbase-10471_v1.patch

This should do the trick. 

 Remove HTD.isAsyncLogFlush() from trunk
 ---

 Key: HBASE-10471
 URL: https://issues.apache.org/jira/browse/HBASE-10471
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.99.0

 Attachments: hbase-10471_v1.patch


 See HBASE-10467 for discussion. We renamed a deprecated method, which we 
 should have removed instead. 
 We will keep the deprecated method in 0.98 (via HBASE-10467) and remove it 
 from trunk. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10472) Manage the interruption in ZKUtil#getData

2014-02-05 Thread Nicolas Liochon (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Liochon updated HBASE-10472:


Status: Patch Available  (was: Open)

 Manage the interruption in ZKUtil#getData
 -

 Key: HBASE-10472
 URL: https://issues.apache.org/jira/browse/HBASE-10472
 Project: HBase
  Issue Type: Bug
  Components: Client, master, regionserver
Affects Versions: 0.98.0, 0.99.0
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
 Fix For: 0.98.1, 0.99.0

 Attachments: 10472.v1.patch


 Many, but not all, methods in ZKUtil partly hides the interruption: they 
 return null or something like that. Many times, this will result in a NPE, or 
 something undefined. 
 This jira is limited to the getData to keep things small enough (it's used in 
 hbase-client code).
 The code is supposed to behave at least 'as well as before', or better 
 (hopefully).
 It could be included in a later .98 release (98.1) and in .99



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10471) Remove HTD.isAsyncLogFlush() from trunk

2014-02-05 Thread Jonathan Hsieh (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892505#comment-13892505
 ] 

Jonathan Hsieh commented on HBASE-10471:


+1

 Remove HTD.isAsyncLogFlush() from trunk
 ---

 Key: HBASE-10471
 URL: https://issues.apache.org/jira/browse/HBASE-10471
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.99.0

 Attachments: hbase-10471_v1.patch


 See HBASE-10467 for discussion. We renamed a deprecated method, which we 
 should have removed instead. 
 We will keep the deprecated method in 0.98 (via HBASE-10467) and remove it 
 from trunk. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10465) TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes

2014-02-05 Thread Andrew Purtell (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell updated HBASE-10465:
---

Fix Version/s: 0.98.0

Committed test fix to 0.98 also.

 TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
 ---

 Key: HBASE-10465
 URL: https://issues.apache.org/jira/browse/HBASE-10465
 Project: HBase
  Issue Type: Test
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.98.0, 0.99.0

 Attachments: hbase-10465.patch


 It looks like sleeping 100 ms is not enough for the permission change to 
 propagate to other watchers. Will increase the sleeping time a little.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10460) Return value of Scan#setSmall() should be void

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892539#comment-13892539
 ] 

Hudson commented on HBASE-10460:


SUCCESS: Integrated in HBase-0.98 #133 (See 
[https://builds.apache.org/job/HBase-0.98/133/])
HBASE-10460 Return value of Scan#setSmall() should be void - Addendum patch to 
fix javadoc warning (enis: rev 1564625)
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Scan.java


 Return value of Scan#setSmall() should be void
 --

 Key: HBASE-10460
 URL: https://issues.apache.org/jira/browse/HBASE-10460
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.0
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0, 0.99.0

 Attachments: 10460.txt, hbase-10460_addendum.patch


 Aleksandr Shulman reported the following incompatibility between 0.96 and 
 0.98 under the '[VOTE] The 1st HBase 0.98.0 release candidate is available 
 for download' thread:
 {code}
 Exception from testScanMeta:  - java.lang.NoSuchMethodError:
 org.apache.hadoop.hbase.client.Scan.setSmall(Z)V
 {code}
 Return value of Scan#setSmall() should be void



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (HBASE-10473) Add utility for adorning http Context

2014-02-05 Thread stack (JIRA)
stack created HBASE-10473:
-

 Summary: Add utility for adorning http Context
 Key: HBASE-10473
 URL: https://issues.apache.org/jira/browse/HBASE-10473
 Project: HBase
  Issue Type: Task
  Components: UI
Reporter: stack
Assignee: stack
 Fix For: 0.98.0, 0.96.2, 0.94.17


Add a utillity class that is used where ever we put up a webserver so we adorn 
http Context the same in all cases.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10467) Restore HTableDescriptor#isDeferredLogFlush()

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892541#comment-13892541
 ] 

Hudson commented on HBASE-10467:


SUCCESS: Integrated in HBase-0.98 #133 (See 
[https://builds.apache.org/job/HBase-0.98/133/])
HBASE-10467 Restore HTableDescriptor#isDeferredLogFlush() (tedyu: rev 1564594)
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestLogRollAbort.java
HBASE-10467 Restore HTableDescriptor#isDeferredLogFlush() (tedyu: rev 1564593)
* 
/hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
HBASE-10467 Restore HTableDescriptor#isDeferredLogFlush() (tedyu: rev 1564589)
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestDurability.java


 Restore HTableDescriptor#isDeferredLogFlush()
 -

 Key: HBASE-10467
 URL: https://issues.apache.org/jira/browse/HBASE-10467
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
 Fix For: 0.98.0

 Attachments: 10467-v2.txt, 10467-v3.txt, 10467.txt


 HTableDescriptor#isDeferredLogFlush() should be restored in 0.98 and marked 
 Deprecated.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892540#comment-13892540
 ] 

Hudson commented on HBASE-10337:


SUCCESS: Integrated in HBase-0.98 #133 (See 
[https://builds.apache.org/job/HBase-0.98/133/])
Amend HBASE-10337 HTable.get() uninteruptible; add missing license headers 
(apurtell: rev 1564863)
* 
/hbase/branches/0.98/hbase-common/src/main/java/org/apache/hadoop/hbase/util/ExceptionUtil.java
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientOperationInterrupt.java
HBASE-10337 HTable.get() uninteruptible (Nicolas Liochon) (apurtell: rev 
1564853)
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCaller.java
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java
* 
/hbase/branches/0.98/hbase-common/src/main/java/org/apache/hadoop/hbase/util/ExceptionUtil.java
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientOperationInterrupt.java


 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337-addendum.patch, 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10473) Add utility for adorning http Context

2014-02-05 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-10473:
--

Attachment: 10473.txt

 Add utility for adorning http Context
 -

 Key: HBASE-10473
 URL: https://issues.apache.org/jira/browse/HBASE-10473
 Project: HBase
  Issue Type: Task
  Components: UI
Reporter: stack
Assignee: stack
 Fix For: 0.98.0, 0.96.2, 0.94.17

 Attachments: 10473.txt


 Add a utillity class that is used where ever we put up a webserver so we 
 adorn http Context the same in all cases.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10473) Add utility for adorning http Context

2014-02-05 Thread Andrew Purtell (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892563#comment-13892563
 ] 

Andrew Purtell commented on HBASE-10473:


+1 for trunk and 0.98

 Add utility for adorning http Context
 -

 Key: HBASE-10473
 URL: https://issues.apache.org/jira/browse/HBASE-10473
 Project: HBase
  Issue Type: Task
  Components: UI
Reporter: stack
Assignee: stack
 Fix For: 0.98.0, 0.96.2, 0.94.17

 Attachments: 10473.txt


 Add a utillity class that is used where ever we put up a webserver so we 
 adorn http Context the same in all cases.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generating huge log file while importing large amounts of data

2014-02-05 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892572#comment-13892572
 ] 

Hadoop QA commented on HBASE-10470:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12627193/trunk-HBASE-10470.patch
  against trunk revision .
  ATTACHMENT ID: 12627193

{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 hadoop1.1{color}.  The patch compiles against the hadoop 
1.1 profile.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 2 
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/8605//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605//console

This message is automatically generated.

 Import generating huge log file while importing large amounts of data
 -

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (HBASE-10474) Fix javadoc warning in MultiResponse

2014-02-05 Thread Ted Yu (JIRA)
Ted Yu created HBASE-10474:
--

 Summary: Fix javadoc warning in MultiResponse
 Key: HBASE-10474
 URL: https://issues.apache.org/jira/browse/HBASE-10474
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Priority: Minor


From 
https://builds.apache.org/job/PreCommit-HBASE-Build/8605/artifact/trunk/patchprocess/patchJavadocWarnings.txt
 :
{code}
[WARNING] 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/MultiResponse.java:72:
 warning - @param argument index is not a parameter name.
[WARNING] 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/MultiResponse.java:72:
 warning - @param argument result is not a parameter name.
{code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892581#comment-13892581
 ] 

Ted Yu commented on HBASE-10470:


Integrated to 0.98 and trunk.

Thanks for the patch, Vasu.

 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-10470:
---

Summary: Import generates huge log file while importing large amounts of 
data  (was: Import generating huge log file while importing large amounts of 
data)

 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10473) Add utility for adorning http Context

2014-02-05 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-10473:
--

Attachment: 10473-094.txt
10473v2.txt

What I applied.

 Add utility for adorning http Context
 -

 Key: HBASE-10473
 URL: https://issues.apache.org/jira/browse/HBASE-10473
 Project: HBase
  Issue Type: Task
  Components: UI
Reporter: stack
Assignee: stack
 Fix For: 0.98.0, 0.96.2, 0.94.17, 1.0.0

 Attachments: 10473-094.txt, 10473.txt, 10473v2.txt


 Add a utillity class that is used where ever we put up a webserver so we 
 adorn http Context the same in all cases.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Resolved] (HBASE-10473) Add utility for adorning http Context

2014-02-05 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack resolved HBASE-10473.
---

   Resolution: Fixed
Fix Version/s: 1.0.0

Committed to all branches.  Resolving.

 Add utility for adorning http Context
 -

 Key: HBASE-10473
 URL: https://issues.apache.org/jira/browse/HBASE-10473
 Project: HBase
  Issue Type: Task
  Components: UI
Reporter: stack
Assignee: stack
 Fix For: 0.98.0, 0.96.2, 0.94.17, 1.0.0

 Attachments: 10473-094.txt, 10473.txt, 10473v2.txt


 Add a utillity class that is used where ever we put up a webserver so we 
 adorn http Context the same in all cases.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Created] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal

2014-02-05 Thread Ted Yu (JIRA)
Ted Yu created HBASE-10475:
--

 Summary: TestRegionServerCoprocessorExceptionWithAbort may timeout 
due to concurrent lease removal
 Key: HBASE-10475
 URL: https://issues.apache.org/jira/browse/HBASE-10475
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Priority: Minor


I got the following test failure:
{code}
testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
  Time elapsed: 0.049 sec   ERROR!
java.lang.Exception: test timed out after 6 milliseconds
at java.lang.Object.wait(Native Method)
at 
org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
at 
org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
at 
org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
at 
org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
at 
org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
{code}
This was due to unexpected LeaseException bringing down region server:
{code}
2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1] 
coprocessor.CoprocessorHost(760): The coprocessor 
org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
 threw an unexpected exception
org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
at 
org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
at 
org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
at 
org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
at 
org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
at 
org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
{code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal

2014-02-05 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-10475:
---

Attachment: 
org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt

 TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent 
 lease removal
 -

 Key: HBASE-10475
 URL: https://issues.apache.org/jira/browse/HBASE-10475
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Priority: Minor
 Attachments: 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt


 I got the following test failure:
 {code}
 testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
   Time elapsed: 0.049 sec   ERROR!
 java.lang.Exception: test timed out after 6 milliseconds
 at java.lang.Object.wait(Native Method)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
 at 
 org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
 at 
 org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
 at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
 at 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
 {code}
 This was due to unexpected LeaseException bringing down region server:
 {code}
 2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1] 
 coprocessor.CoprocessorHost(760): The coprocessor 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
  threw an unexpected exception
 org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
   at 
 org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
   at 
 org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
   at 
 org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal

2014-02-05 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-10475:
---

Attachment: 10475-v1.txt

 TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent 
 lease removal
 -

 Key: HBASE-10475
 URL: https://issues.apache.org/jira/browse/HBASE-10475
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Priority: Minor
 Attachments: 10475-v1.txt, 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt


 I got the following test failure:
 {code}
 testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
   Time elapsed: 0.049 sec   ERROR!
 java.lang.Exception: test timed out after 6 milliseconds
 at java.lang.Object.wait(Native Method)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
 at 
 org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
 at 
 org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
 at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
 at 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
 {code}
 This was due to unexpected LeaseException bringing down region server:
 {code}
 2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1] 
 coprocessor.CoprocessorHost(760): The coprocessor 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
  threw an unexpected exception
 org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
   at 
 org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
   at 
 org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
   at 
 org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal

2014-02-05 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-10475:
---

Status: Patch Available  (was: Open)

 TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent 
 lease removal
 -

 Key: HBASE-10475
 URL: https://issues.apache.org/jira/browse/HBASE-10475
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Priority: Minor
 Attachments: 10475-v1.txt, 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt


 I got the following test failure:
 {code}
 testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
   Time elapsed: 0.049 sec   ERROR!
 java.lang.Exception: test timed out after 6 milliseconds
 at java.lang.Object.wait(Native Method)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
 at 
 org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
 at 
 org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
 at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
 at 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
 {code}
 This was due to unexpected LeaseException bringing down region server:
 {code}
 2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1] 
 coprocessor.CoprocessorHost(760): The coprocessor 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
  threw an unexpected exception
 org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
   at 
 org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
   at 
 org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
   at 
 org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Assigned] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal

2014-02-05 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu reassigned HBASE-10475:
--

Assignee: Ted Yu

 TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent 
 lease removal
 -

 Key: HBASE-10475
 URL: https://issues.apache.org/jira/browse/HBASE-10475
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Minor
 Attachments: 10475-v1.txt, 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt


 I got the following test failure:
 {code}
 testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
   Time elapsed: 0.049 sec   ERROR!
 java.lang.Exception: test timed out after 6 milliseconds
 at java.lang.Object.wait(Native Method)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
 at 
 org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
 at 
 org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
 at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
 at 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
 {code}
 This was due to unexpected LeaseException bringing down region server:
 {code}
 2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1] 
 coprocessor.CoprocessorHost(760): The coprocessor 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
  threw an unexpected exception
 org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
   at 
 org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
   at 
 org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
   at 
 org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Lars Hofhansl (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892615#comment-13892615
 ] 

Lars Hofhansl commented on HBASE-10470:
---

I'll commit this to 0.94 and 0.96 ([~stack] assuming you want this)

 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892616#comment-13892616
 ] 

Hudson commented on HBASE-10337:


SUCCESS: Integrated in HBase-0.98-on-Hadoop-1.1 #124 (See 
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/124/])
HBASE-10337 HTable.get() uninteruptible (Nicolas Liochon) (apurtell: rev 
1564853)
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCaller.java
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java
* 
/hbase/branches/0.98/hbase-common/src/main/java/org/apache/hadoop/hbase/util/ExceptionUtil.java
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientOperationInterrupt.java


 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337-addendum.patch, 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Comment Edited] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Lars Hofhansl (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892615#comment-13892615
 ] 

Lars Hofhansl edited comment on HBASE-10470 at 2/5/14 9:51 PM:
---

I'll commit this to 0.94 and 0.96 ([~stack] assuming you want this)
So that Andy can close this for the RC.


was (Author: lhofhansl):
I'll commit this to 0.94 and 0.96 ([~stack] assuming you want this)

 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal

2014-02-05 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892630#comment-13892630
 ] 

Ted Yu commented on HBASE-10475:


Looped TestRegionServerCoprocessorExceptionWithAbort 12 times and they passed.

 TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent 
 lease removal
 -

 Key: HBASE-10475
 URL: https://issues.apache.org/jira/browse/HBASE-10475
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Minor
 Attachments: 10475-v1.txt, 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt


 I got the following test failure:
 {code}
 testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
   Time elapsed: 0.049 sec   ERROR!
 java.lang.Exception: test timed out after 6 milliseconds
 at java.lang.Object.wait(Native Method)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
 at 
 org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
 at 
 org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
 at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
 at 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
 {code}
 This was due to unexpected LeaseException bringing down region server:
 {code}
 2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1] 
 coprocessor.CoprocessorHost(760): The coprocessor 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
  threw an unexpected exception
 org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
   at 
 org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
   at 
 org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
   at 
 org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Comment Edited] (HBASE-10475) TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent lease removal

2014-02-05 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892630#comment-13892630
 ] 

Ted Yu edited comment on HBASE-10475 at 2/5/14 10:11 PM:
-

Looped TestRegionServerCoprocessorExceptionWithAbort with patch 12 times and 
they passed.


was (Author: yuzhih...@gmail.com):
Looped TestRegionServerCoprocessorExceptionWithAbort 12 times and they passed.

 TestRegionServerCoprocessorExceptionWithAbort may timeout due to concurrent 
 lease removal
 -

 Key: HBASE-10475
 URL: https://issues.apache.org/jira/browse/HBASE-10475
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Minor
 Attachments: 10475-v1.txt, 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort-output.txt


 I got the following test failure:
 {code}
 testExceptionFromCoprocessorDuringPut(org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort)
   Time elapsed: 0.049 sec   ERROR!
 java.lang.Exception: test timed out after 6 milliseconds
 at java.lang.Object.wait(Native Method)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForNextTaskDone(AsyncProcess.java:837)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitForMaximumCurrentTasks(AsyncProcess.java:863)
 at 
 org.apache.hadoop.hbase.client.AsyncProcess.waitUntilDone(AsyncProcess.java:876)
 at 
 org.apache.hadoop.hbase.client.HTable.backgroundFlushCommits(HTable.java:945)
 at 
 org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1225)
 at org.apache.hadoop.hbase.client.HTable.put(HTable.java:887)
 at 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort.testExceptionFromCoprocessorDuringPut(TestRegionServerCoprocessorExceptionWithAbort.java:106)
 {code}
 This was due to unexpected LeaseException bringing down region server:
 {code}
 2014-02-05 19:28:24,752 ERROR [RS_OPEN_REGION-kiyo:56349-1] 
 coprocessor.CoprocessorHost(760): The coprocessor 
 org.apache.hadoop.hbase.coprocessor.TestRegionServerCoprocessorExceptionWithAbort$BuggyRegionObserver
  threw an unexpected exception
 org.apache.hadoop.hbase.regionserver.LeaseException: lease 'x' does not exist
   at 
 org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:221)
   at 
 org.apache.hadoop.hbase.regionserver.Leases.cancelLease(Leases.java:206)
   at 
 org.apache.hadoop.hbase.coprocessor.SimpleRegionObserver.start(SimpleRegionObserver.java:140)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.startup(CoprocessorHost.java:651)
   at 
 org.apache.hadoop.hbase.coprocessor.CoprocessorHost.loadInstance(CoprocessorHost.java:261)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Lars Hofhansl (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl updated HBASE-10470:
--

Attachment: 10470.txt

0.96 patch.
Makes it the same as 0.94.

 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, 10470.txt, 
 trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Lars Hofhansl (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl updated HBASE-10470:
--

  Resolution: Fixed
Release Note: Committed to 0.94 and 0.96 as well.
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, 10470.txt, 
 trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10465) TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892663#comment-13892663
 ] 

Hudson commented on HBASE-10465:


FAILURE: Integrated in HBase-TRUNK #4889 (See 
[https://builds.apache.org/job/HBase-TRUNK/4889/])
HBASE-10465 TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes 
(jxiang: rev 1564881)
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestZKPermissionsWatcher.java


 TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
 ---

 Key: HBASE-10465
 URL: https://issues.apache.org/jira/browse/HBASE-10465
 Project: HBase
  Issue Type: Test
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.98.0, 0.99.0

 Attachments: hbase-10465.patch


 It looks like sleeping 100 ms is not enough for the permission change to 
 propagate to other watchers. Will increase the sleeping time a little.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892658#comment-13892658
 ] 

Hudson commented on HBASE-10470:


FAILURE: Integrated in HBase-0.94-security #400 (See 
[https://builds.apache.org/job/HBase-0.94-security/400/])
HBASE-10470 Import generates huge log file while importing large amounts of 
data. (Vasu Mariyala) (larsh: rev 1564950)
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/mapreduce/Import.java


 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, 10470.txt, 
 trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10473) Add utility for adorning http Context

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892657#comment-13892657
 ] 

Hudson commented on HBASE-10473:


FAILURE: Integrated in HBase-0.94-security #400 (See 
[https://builds.apache.org/job/HBase-0.94-security/400/])
HBASE-10473 Add utility for adorning http Context (stack: rev 1564936)
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/rest/Main.java
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/HttpServerUtil.java
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/InfoServer.java
* 
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/rest/HBaseRESTTestingUtility.java


 Add utility for adorning http Context
 -

 Key: HBASE-10473
 URL: https://issues.apache.org/jira/browse/HBASE-10473
 Project: HBase
  Issue Type: Task
  Components: UI
Reporter: stack
Assignee: stack
 Fix For: 0.98.0, 0.96.2, 0.94.17, 1.0.0

 Attachments: 10473-094.txt, 10473.txt, 10473v2.txt


 Add a utillity class that is used where ever we put up a webserver so we 
 adorn http Context the same in all cases.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10277) refactor AsyncProcess

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892662#comment-13892662
 ] 

Hudson commented on HBASE-10277:


FAILURE: Integrated in HBase-TRUNK #4889 (See 
[https://builds.apache.org/job/HBase-TRUNK/4889/])
HBASE-10277 refactor AsyncProcess (sershe: rev 1564832)
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncProcess.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HConnection.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/MultiResponse.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RetriesExhaustedWithDetailsException.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ResponseConverter.java
* 
/hbase/trunk/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAsyncProcess.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/client/CoprocessorHConnection.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/HConnectionTestingUtility.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestCatalogJanitor.java


 refactor AsyncProcess
 -

 Key: HBASE-10277
 URL: https://issues.apache.org/jira/browse/HBASE-10277
 Project: HBase
  Issue Type: Improvement
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
 Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, 
 HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch, 
 HBASE-10277.06.patch, HBASE-10277.07.patch, HBASE-10277.patch


 AsyncProcess currently has two patterns of usage, one from HTable flush w/o 
 callback and with reuse, and one from HCM/HTable batch call, with callback 
 and w/o reuse. In the former case (but not the latter), it also does some 
 throttling of actions on initial submit call, limiting the number of 
 outstanding actions per server.
 The latter case is relatively straightforward. The former appears to be error 
 prone due to reuse - if, as javadoc claims should be safe, multiple submit 
 calls are performed without waiting for the async part of the previous call 
 to finish, fields like hasError become ambiguous and can be used for the 
 wrong call; callback for success/failure is called based on original index 
 of an action in submitted list, but with only one callback supplied to AP in 
 ctor it's not clear to which submit call the index belongs, if several are 
 outstanding.
 I was going to add support for HBASE-10070 to AP, and found that it might be 
 difficult to do cleanly.
 It would be nice to normalize AP usage patterns; in particular, separate the 
 global part (load tracking) from per-submit-call part.
 Per-submit part can more conveniently track stuff like initialActions, 
 mapping of indexes and retry information, that is currently passed around the 
 method calls.
 -I am not sure yet, but maybe sending of the original index to server in 
 ClientProtos.MultiAction can also be avoided.- Cannot be avoided because 
 the API to server doesn't have one-to-one correspondence between requests and 
 responses in an individual call to multi (retries/rearrangement have nothing 
 to do with it)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10337) HTable.get() uninteruptible

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892661#comment-13892661
 ] 

Hudson commented on HBASE-10337:


FAILURE: Integrated in HBase-TRUNK #4889 (See 
[https://builds.apache.org/job/HBase-TRUNK/4889/])
Amend HBASE-10337 HTable.get() uninteruptible; add missing license headers 
(apurtell: rev 1564861)
* 
/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/ExceptionUtil.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientOperationInterrupt.java
HBASE-10337 HTable.get() uninteruptible (Nicolas Liochon) (apurtell: rev 
1564851)
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCaller.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java
* 
/hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/ExceptionUtil.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientOperationInterrupt.java


 HTable.get() uninteruptible
 ---

 Key: HBASE-10337
 URL: https://issues.apache.org/jira/browse/HBASE-10337
 Project: HBase
  Issue Type: Bug
  Components: Client
Affects Versions: 0.98.0, 0.94.9, 0.99.0, 0.96.1.1
Reporter: Jonathan Leech
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.99.0

 Attachments: 10337-addendum.patch, 10337.v1.patch, 10337.v2.patch


 I've got a stuck thread on HTable.get() that can't be interrupted, looks like 
 its designed to be interruptible but can't be in interrupted in practice due 
 to while loop.
 The offending code is in org.apache.hadoop.hbase.ipc.HBaseClient.call() line 
 981, it catches InterruptedException then goes right back to waiting due to 
 the while loop.
 It looks like future versions of the client (.95+) are significantly 
 different and might not have this problem... Not sure about release schedules 
 etc. or if this version is still getting patched.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892689#comment-13892689
 ] 

Hudson commented on HBASE-10470:


FAILURE: Integrated in HBase-0.94-on-Hadoop-2 #10 (See 
[https://builds.apache.org/job/HBase-0.94-on-Hadoop-2/10/])
HBASE-10470 Import generates huge log file while importing large amounts of 
data. (Vasu Mariyala) (larsh: rev 1564950)
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/mapreduce/Import.java


 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, 10470.txt, 
 trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10473) Add utility for adorning http Context

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892688#comment-13892688
 ] 

Hudson commented on HBASE-10473:


FAILURE: Integrated in HBase-0.94-on-Hadoop-2 #10 (See 
[https://builds.apache.org/job/HBase-0.94-on-Hadoop-2/10/])
HBASE-10473 Add utility for adorning http Context (stack: rev 1564936)
* /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/rest/Main.java
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/HttpServerUtil.java
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/util/InfoServer.java
* 
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/rest/HBaseRESTTestingUtility.java


 Add utility for adorning http Context
 -

 Key: HBASE-10473
 URL: https://issues.apache.org/jira/browse/HBASE-10473
 Project: HBase
  Issue Type: Task
  Components: UI
Reporter: stack
Assignee: stack
 Fix For: 0.98.0, 0.96.2, 0.94.17, 1.0.0

 Attachments: 10473-094.txt, 10473.txt, 10473v2.txt


 Add a utillity class that is used where ever we put up a webserver so we 
 adorn http Context the same in all cases.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Assigned] (HBASE-5356) region_mover.rb can hang if table region it belongs to is deleted.

2014-02-05 Thread Jimmy Xiang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jimmy Xiang reassigned HBASE-5356:
--

Assignee: Jimmy Xiang  (was: Jonathan Hsieh)

 region_mover.rb can hang if table region it belongs to is deleted.
 --

 Key: HBASE-5356
 URL: https://issues.apache.org/jira/browse/HBASE-5356
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.90.3, 0.92.0, 0.94.0
Reporter: Jonathan Hsieh
Assignee: Jimmy Xiang
Priority: Minor

 I was testing the region_mover.rb script on a loaded hbase and noticed that 
 it can hang (thus hanging graceful shutdown) if a region that it is 
 attempting to move gets deleted (by a table delete operation).
 Here's the start of the relevent stack dump
 {code}
 12/02/08 13:27:13 WARN client.HConnectionManager$HConnectionImplementation: 
 Encountered problems when prefetch META table:
 org.apache.hadoop.hbase.TableNotFoundException: Cannot find row in .META. for 
 table: TestLoadAndVerify_1328735001040, row=TestLoadAnd\
 Verify_1328735001040,yC^P\xD7\x945\xD4,99
 at 
 org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:136)
 at 
 org.apache.hadoop.hbase.client.MetaScanner.metaScan(MetaScanner.java:95)
 at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.prefetchRegionCache(HConnectionManager.java:64\
 9)
 at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegionInMeta(HConnectionManager.java:703\
 )
 at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.locateRegion(HConnectionManager.java:594)
 at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.relocateRegion(HConnectionManager.java:565)
 at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionLocation(HConnectionManager.java:416)
 at 
 org.apache.hadoop.hbase.client.ServerCallable.instantiateServer(ServerCallable.java:57)
 at 
 org.apache.hadoop.hbase.client.ScannerCallable.instantiateServer(ScannerCallable.java:63)
 at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getRegionServerWithRetries(HConnectionManager.\
 java:1018)
 at 
 org.apache.hadoop.hbase.client.HTable$ClientScanner.nextScanner(HTable.java:1104)
 at 
 org.apache.hadoop.hbase.client.HTable$ClientScanner.initialize(HTable.java:1027)
 at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:535)
 at sun.reflect.GeneratedMethodAccessor24.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 org.jruby.javasupport.JavaMethod.invokeDirectWithExceptionHandling(JavaMethod.java:525)
 at org.jruby.javasupport.JavaMethod.invokeDirect(JavaMethod.java:380)
 at 
 org.jruby.java.invokers.InstanceMethodInvoker.call(InstanceMethodInvoker.java:58)
 at 
 org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:137)
 at 
 usr.lib.hbase.bin.region_mover.method__7$RUBY$isSuccessfulScan(/usr/lib/hbase/bin/region_mover.rb:133)
 at 
 usr$lib$hbase$bin$region_mover#method__7$RUBY$isSuccessfulScan.call(usr$lib$hbase$bin$region_mover#method__7$RUBY$isSucces\
 sfulScan:65535)
 at 
 usr$lib$hbase$bin$region_mover#method__7$RUBY$isSuccessfulScan.call(usr$lib$hbase$bin$region_mover#method__7$RUBY$isSucces\
 sfulScan:65535)
 at 
 org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:171)
 at 
 usr.lib.hbase.bin.region_mover.block_4$RUBY$__for__(/usr/lib/hbase/bin/region_mover.rb:326)
 at 
 usr$lib$hbase$bin$region_mover#block_4$RUBY$__for__.call(usr$lib$hbase$bin$region_mover#block_4$RUBY$__for__:65535)
 at org.jruby.runtime.CompiledBlock.yield(CompiledBlock.java:133)
 at org.jruby.runtime.BlockBody.call(BlockBody.java:73)
 at org.jruby.runtime.Block.call(Block.java:89)
 at org.jruby.RubyProc.call(RubyProc.java:268)
 at org.jruby.RubyProc.call(RubyProc.java:228)
 at org.jruby.RubyProc$i$0$0$call.call(RubyProc$i$0$0$call.gen:65535)
 at 
 org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:209)
 at 
 org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:205)
 at 
 org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:137)
 at org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
 at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:103)
 at org.jruby.ast.WhileNode.interpret(WhileNode.java:131)
 at 

[jira] [Commented] (HBASE-10471) Remove HTD.isAsyncLogFlush() from trunk

2014-02-05 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892711#comment-13892711
 ] 

Hadoop QA commented on HBASE-10471:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12627197/hbase-10471_v1.patch
  against trunk revision .
  ATTACHMENT ID: 12627197

{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 hadoop1.1{color}.  The patch compiles against the hadoop 
1.1 profile.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 2 
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:red}-1 core tests{color}.  The patch failed these unit tests:
 

 {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s): 

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8606//console

This message is automatically generated.

 Remove HTD.isAsyncLogFlush() from trunk
 ---

 Key: HBASE-10471
 URL: https://issues.apache.org/jira/browse/HBASE-10471
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.99.0

 Attachments: hbase-10471_v1.patch


 See HBASE-10467 for discussion. We renamed a deprecated method, which we 
 should have removed instead. 
 We will keep the deprecated method in 0.98 (via HBASE-10467) and remove it 
 from trunk. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10277) refactor AsyncProcess

2014-02-05 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-10277:
---

Fix Version/s: 0.99.0

 refactor AsyncProcess
 -

 Key: HBASE-10277
 URL: https://issues.apache.org/jira/browse/HBASE-10277
 Project: HBase
  Issue Type: Improvement
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
 Fix For: 0.99.0

 Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, 
 HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch, 
 HBASE-10277.06.patch, HBASE-10277.07.patch, HBASE-10277.patch


 AsyncProcess currently has two patterns of usage, one from HTable flush w/o 
 callback and with reuse, and one from HCM/HTable batch call, with callback 
 and w/o reuse. In the former case (but not the latter), it also does some 
 throttling of actions on initial submit call, limiting the number of 
 outstanding actions per server.
 The latter case is relatively straightforward. The former appears to be error 
 prone due to reuse - if, as javadoc claims should be safe, multiple submit 
 calls are performed without waiting for the async part of the previous call 
 to finish, fields like hasError become ambiguous and can be used for the 
 wrong call; callback for success/failure is called based on original index 
 of an action in submitted list, but with only one callback supplied to AP in 
 ctor it's not clear to which submit call the index belongs, if several are 
 outstanding.
 I was going to add support for HBASE-10070 to AP, and found that it might be 
 difficult to do cleanly.
 It would be nice to normalize AP usage patterns; in particular, separate the 
 global part (load tracking) from per-submit-call part.
 Per-submit part can more conveniently track stuff like initialActions, 
 mapping of indexes and retry information, that is currently passed around the 
 method calls.
 -I am not sure yet, but maybe sending of the original index to server in 
 ClientProtos.MultiAction can also be avoided.- Cannot be avoided because 
 the API to server doesn't have one-to-one correspondence between requests and 
 responses in an individual call to multi (retries/rearrangement have nothing 
 to do with it)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Nick Dimiduk (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Dimiduk updated HBASE-10470:
-

Assignee: Vasu Mariyala

 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Assignee: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, 10470.txt, 
 trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10472) Manage the interruption in ZKUtil#getData

2014-02-05 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892741#comment-13892741
 ] 

Hadoop QA commented on HBASE-10472:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12627199/10472.v1.patch
  against trunk revision .
  ATTACHMENT ID: 12627199

{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 hadoop1.1{color}.  The patch compiles against the hadoop 
1.1 profile.

{color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 2 
warning messages.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:red}-1 findbugs{color}.  The patch appears to introduce 4 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/8607//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8607//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8607//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8607//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8607//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8607//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8607//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8607//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8607//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8607//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/8607//console

This message is automatically generated.

 Manage the interruption in ZKUtil#getData
 -

 Key: HBASE-10472
 URL: https://issues.apache.org/jira/browse/HBASE-10472
 Project: HBase
  Issue Type: Bug
  Components: Client, master, regionserver
Affects Versions: 0.98.0, 0.99.0
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
 Fix For: 0.98.1, 0.99.0

 Attachments: 10472.v1.patch


 Many, but not all, methods in ZKUtil partly hides the interruption: they 
 return null or something like that. Many times, this will result in a NPE, or 
 something undefined. 
 This jira is limited to the getData to keep things small enough (it's used in 
 hbase-client code).
 The code is supposed to behave at least 'as well as before', or better 
 (hopefully).
 It could be included in a later .98 release (98.1) and in .99



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10348) HTableDescriptor changes for region replicas

2014-02-05 Thread Devaraj Das (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892757#comment-13892757
 ] 

Devaraj Das commented on HBASE-10348:
-

Does anyone want to take a look at this before commit.

 HTableDescriptor changes for region replicas
 

 Key: HBASE-10348
 URL: https://issues.apache.org/jira/browse/HBASE-10348
 Project: HBase
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Devaraj Das
 Fix For: 0.99.0

 Attachments: 10348-1.txt


 Region replication should be configurable per table. Thus we can add an 
 attribute to indicate the desired region replication count to 
 HTableDescriptor. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10473) Add utility for adorning http Context

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892762#comment-13892762
 ] 

Hudson commented on HBASE-10473:


SUCCESS: Integrated in HBase-0.98 #135 (See 
[https://builds.apache.org/job/HBase-0.98/135/])
HBASE-10473 Add utility for adorning http Context (stack: rev 1564929)
* 
/hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/rest/RESTServer.java
* 
/hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HttpServerUtil.java
* 
/hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/util/InfoServer.java
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/rest/HBaseRESTTestingUtility.java


 Add utility for adorning http Context
 -

 Key: HBASE-10473
 URL: https://issues.apache.org/jira/browse/HBASE-10473
 Project: HBase
  Issue Type: Task
  Components: UI
Reporter: stack
Assignee: stack
 Fix For: 0.98.0, 0.96.2, 0.94.17, 1.0.0

 Attachments: 10473-094.txt, 10473.txt, 10473v2.txt


 Add a utillity class that is used where ever we put up a webserver so we 
 adorn http Context the same in all cases.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10465) TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892764#comment-13892764
 ] 

Hudson commented on HBASE-10465:


SUCCESS: Integrated in HBase-0.98 #135 (See 
[https://builds.apache.org/job/HBase-0.98/135/])
HBASE-10465 TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes 
(Jimmy Xiang) (apurtell: rev 1564909)
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestZKPermissionsWatcher.java


 TestZKPermissionsWatcher.testPermissionsWatcher fails sometimes
 ---

 Key: HBASE-10465
 URL: https://issues.apache.org/jira/browse/HBASE-10465
 Project: HBase
  Issue Type: Test
Reporter: Jimmy Xiang
Assignee: Jimmy Xiang
Priority: Trivial
 Fix For: 0.98.0, 0.99.0

 Attachments: hbase-10465.patch


 It looks like sleeping 100 ms is not enough for the permission change to 
 propagate to other watchers. Will increase the sleeping time a little.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892763#comment-13892763
 ] 

Hudson commented on HBASE-10470:


SUCCESS: Integrated in HBase-0.98 #135 (See 
[https://builds.apache.org/job/HBase-0.98/135/])
HBASE-10470 Import generates huge log file while importing large amounts of 
data (Vasu Mariyala) (tedyu: rev 1564932)
* 
/hbase/branches/0.98/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/Import.java


 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Assignee: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, 10470.txt, 
 trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10277) refactor AsyncProcess

2014-02-05 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892769#comment-13892769
 ] 

Enis Soztutar commented on HBASE-10277:
---

Sergey did you commit this? An update would have been nice. Also there seems to 
be javadoc warnings. Can you do an addendum patch for fixing those. 

 refactor AsyncProcess
 -

 Key: HBASE-10277
 URL: https://issues.apache.org/jira/browse/HBASE-10277
 Project: HBase
  Issue Type: Improvement
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
 Fix For: 0.99.0

 Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, 
 HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch, 
 HBASE-10277.06.patch, HBASE-10277.07.patch, HBASE-10277.patch


 AsyncProcess currently has two patterns of usage, one from HTable flush w/o 
 callback and with reuse, and one from HCM/HTable batch call, with callback 
 and w/o reuse. In the former case (but not the latter), it also does some 
 throttling of actions on initial submit call, limiting the number of 
 outstanding actions per server.
 The latter case is relatively straightforward. The former appears to be error 
 prone due to reuse - if, as javadoc claims should be safe, multiple submit 
 calls are performed without waiting for the async part of the previous call 
 to finish, fields like hasError become ambiguous and can be used for the 
 wrong call; callback for success/failure is called based on original index 
 of an action in submitted list, but with only one callback supplied to AP in 
 ctor it's not clear to which submit call the index belongs, if several are 
 outstanding.
 I was going to add support for HBASE-10070 to AP, and found that it might be 
 difficult to do cleanly.
 It would be nice to normalize AP usage patterns; in particular, separate the 
 global part (load tracking) from per-submit-call part.
 Per-submit part can more conveniently track stuff like initialActions, 
 mapping of indexes and retry information, that is currently passed around the 
 method calls.
 -I am not sure yet, but maybe sending of the original index to server in 
 ClientProtos.MultiAction can also be avoided.- Cannot be avoided because 
 the API to server doesn't have one-to-one correspondence between requests and 
 responses in an individual call to multi (retries/rearrangement have nothing 
 to do with it)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10277) refactor AsyncProcess

2014-02-05 Thread Enis Soztutar (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892770#comment-13892770
 ] 

Enis Soztutar commented on HBASE-10277:
---

Can you also resolve the issue. 

 refactor AsyncProcess
 -

 Key: HBASE-10277
 URL: https://issues.apache.org/jira/browse/HBASE-10277
 Project: HBase
  Issue Type: Improvement
Reporter: Sergey Shelukhin
Assignee: Sergey Shelukhin
 Fix For: 0.99.0

 Attachments: HBASE-10277.01.patch, HBASE-10277.02.patch, 
 HBASE-10277.03.patch, HBASE-10277.04.patch, HBASE-10277.05.patch, 
 HBASE-10277.06.patch, HBASE-10277.07.patch, HBASE-10277.patch


 AsyncProcess currently has two patterns of usage, one from HTable flush w/o 
 callback and with reuse, and one from HCM/HTable batch call, with callback 
 and w/o reuse. In the former case (but not the latter), it also does some 
 throttling of actions on initial submit call, limiting the number of 
 outstanding actions per server.
 The latter case is relatively straightforward. The former appears to be error 
 prone due to reuse - if, as javadoc claims should be safe, multiple submit 
 calls are performed without waiting for the async part of the previous call 
 to finish, fields like hasError become ambiguous and can be used for the 
 wrong call; callback for success/failure is called based on original index 
 of an action in submitted list, but with only one callback supplied to AP in 
 ctor it's not clear to which submit call the index belongs, if several are 
 outstanding.
 I was going to add support for HBASE-10070 to AP, and found that it might be 
 difficult to do cleanly.
 It would be nice to normalize AP usage patterns; in particular, separate the 
 global part (load tracking) from per-submit-call part.
 Per-submit part can more conveniently track stuff like initialActions, 
 mapping of indexes and retry information, that is currently passed around the 
 method calls.
 -I am not sure yet, but maybe sending of the original index to server in 
 ClientProtos.MultiAction can also be avoided.- Cannot be avoided because 
 the API to server doesn't have one-to-one correspondence between requests and 
 responses in an individual call to multi (retries/rearrangement have nothing 
 to do with it)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Updated] (HBASE-10471) Remove HTD.isAsyncLogFlush() from trunk

2014-02-05 Thread Enis Soztutar (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-10471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Enis Soztutar updated HBASE-10471:
--

  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Committed this. Thanks Jon for review. Javadoc and test failures are not 
related. 

 Remove HTD.isAsyncLogFlush() from trunk
 ---

 Key: HBASE-10471
 URL: https://issues.apache.org/jira/browse/HBASE-10471
 Project: HBase
  Issue Type: Improvement
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 0.99.0

 Attachments: hbase-10471_v1.patch


 See HBASE-10467 for discussion. We renamed a deprecated method, which we 
 should have removed instead. 
 We will keep the deprecated method in 0.98 (via HBASE-10467) and remove it 
 from trunk. 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


[jira] [Commented] (HBASE-10470) Import generates huge log file while importing large amounts of data

2014-02-05 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-10470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13892780#comment-13892780
 ] 

Hudson commented on HBASE-10470:


SUCCESS: Integrated in HBase-0.94-JDK7 #39 (See 
[https://builds.apache.org/job/HBase-0.94-JDK7/39/])
HBASE-10470 Import generates huge log file while importing large amounts of 
data. (Vasu Mariyala) (larsh: rev 1564950)
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/mapreduce/Import.java


 Import generates huge log file while importing large amounts of data
 

 Key: HBASE-10470
 URL: https://issues.apache.org/jira/browse/HBASE-10470
 Project: HBase
  Issue Type: Bug
Reporter: Vasu Mariyala
Assignee: Vasu Mariyala
Priority: Critical
 Fix For: 0.98.0, 0.96.2, 0.99.0, 0.94.17

 Attachments: 0.94-HBASE-10470.patch, 10470.txt, 
 trunk-HBASE-10470.patch


 Import mapper has System.out.println statements for each key value if there 
 is filter associated with the import. This is generating huge log file while 
 importing large amounts of data. These statements must be changed to trace 
 and log4j must be used for logging.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)


  1   2   >