date:20130409

[jira] [Commented] (HBASE-8045) Fix .META. migration after HBASE-3171

2013-04-09 Thread stack (JIRA)


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

stack commented on HBASE-8045:
--

Patch looks good to me [~rajesh23]  Thanks for working on this.  The test case 
should catch any issues migrating from old 0.92 to 0.96 so I think this is good 
to go... If teething issues, can open new issues.

 Fix .META. migration after HBASE-3171
 -

 Key: HBASE-8045
 URL: https://issues.apache.org/jira/browse/HBASE-8045
 Project: HBase
  Issue Type: Task
Reporter: Jean-Daniel Cryans
Priority: Blocker
 Fix For: 0.95.1

 Attachments: HBASE-8045_2.patch, HBASE-8045_3.patch, HBASE-8045.patch


 HBASE-3171 doesn't manage the migration correctly, see 
 MetaMigrationConvertingToPB and its unit test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-8045) Fix .META. migration after HBASE-3171

2013-04-09 Thread stack (JIRA)


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

stack updated HBASE-8045:
-

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

Committed to trunk.  Thanks for the patch Rajesh (and for review Sergey)

 Fix .META. migration after HBASE-3171
 -

 Key: HBASE-8045
 URL: https://issues.apache.org/jira/browse/HBASE-8045
 Project: HBase
  Issue Type: Task
Reporter: Jean-Daniel Cryans
Assignee: rajeshbabu
Priority: Blocker
 Fix For: 0.95.1

 Attachments: HBASE-8045_2.patch, HBASE-8045_3.patch, HBASE-8045.patch


 HBASE-3171 doesn't manage the migration correctly, see 
 MetaMigrationConvertingToPB and its unit test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-8294) Make HBaseConfiguration a singleton class

2013-04-09 Thread stack (JIRA)

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

stack commented on HBASE-8294:
--

bq. Ideally, we would like to have just one configuration object in the jvm.

Definitely do not want this in tests -- it is fundamental to quite a few tests
that we can float a different Configuration per daemon (e.g. so different
'Users' on hdfs).

In client, you can ask for new connection by specifying a new Configuration so
being able to have a new Config instance is important currently.

On server, there has been various juggling of the Configuration instance to do
things like a per column family 'view' on Configuration to do stuff like
dynamic config.

I'd say call it out as a heavyweight construction and close as Invalid at least
until there is a better reason for changing how we treat Configuration.

Make HBaseConfiguration a singleton class
-

Key: HBASE-8294
URL: https://issues.apache.org/jira/browse/HBASE-8294
Project: HBase
Issue Type: Improvement
Components: master, regionserver
Affects Versions: 0.95.0
Reporter: Himanshu Vashishtha
Assignee: Himanshu Vashishtha

HBaseConfiguration.create() calls a new Configuration object. Ideally, we
would like to have just one configuration object in the jvm.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-8258) Make mapreduce tests pass on hadoop2

2013-04-09 Thread stack (JIRA)


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

stack commented on HBASE-8258:
--

[~ted_yu] Did you even look to see why the tests fail?  What you have pasted, a 
list of test failures that seem unrelated, is close to zero help.

[~jmhsieh]
bq. I disagree with stack's comment...

Fair enough.  If can get this to work w/ current hadoop2, good.  If fails 
against 2.0.4-SNAPSHOT, we should figure why but we would be in a better 
position if it first was working (and we knew why it had not been working 
previously).

 Make mapreduce tests pass on hadoop2
 

 Key: HBASE-8258
 URL: https://issues.apache.org/jira/browse/HBASE-8258
 Project: HBase
  Issue Type: Bug
  Components: mapreduce
Reporter: stack
Priority: Blocker
 Fix For: 0.95.1

 Attachments: 8258-plain.txt, 8258-v1-hadoop-2.0.txt, 
 8258-v2-hadoop-2.0.txt, 8258-v4-hadoop-2.0.txt, hbase-8258-simple.patch, 
 hbase-8258.simple.v2.patch, hbase-8258.simple.v3.patch


 HBASE-7904 was a first attempt at making this work but it got lost in the 
 weeds.
 This is a new attempt at making hbase mapreduce jobs run on hadoop2 (w/o 
 breaking mapreduce on hadoop1)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (HBASE-3967) Support deletes in HFileOutputFormat based bulk import mechanism

2013-04-09 Thread stack (JIRA)


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

stack resolved HBASE-3967.
--

Resolution: Not A Problem
  Assignee: Nick Dimiduk

Assigning Nick -- since he did the work to verify what we suspected, that this 
was already being covered in post 0.89 patches (Thanks Nick).  Resolving as 
'Not a Problem' at Sergey's prompting.

 Support deletes in HFileOutputFormat based bulk import mechanism
 

 Key: HBASE-3967
 URL: https://issues.apache.org/jira/browse/HBASE-3967
 Project: HBase
  Issue Type: Sub-task
  Components: mapreduce
Reporter: Kannan Muthukkaruppan
Assignee: Nick Dimiduk
Priority: Critical
 Fix For: 0.95.1

 Attachments: 3967-janky-verify.patch, diff.patch


 During bulk imports, it'll be useful to be able to do delete mutations 
 (either to delete data that already exists in HBase or was inserted earlier 
 during this run of the import). 
 For example, we have a use case, where we are processing a log of data which 
 may have both inserts and deletes in the mix and we want to upload that into 
 HBase using the bulk import mechanism.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-7028) Bump JRuby to 1.7.0

2013-04-09 Thread Elliott Clark (JIRA)


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

Elliott Clark commented on HBASE-7028:
--

Ran this twenty times taking the min: 
{code}
require 'benchmark'
Benchmark.bm { |x|  x.report('Scan Meta') { for i in 1..500; scan '.META.'; end 
} }
{code}

h3.Current
{noformat}
user system  totalreal
1.844000   0.00   1.844000 (  1.845000)
{noformat}
h3.1.7.3
{noformat}
user system  totalreal
0.96   0.28   1.24 (  1.691000)
{noformat}

 Bump JRuby to 1.7.0
 ---

 Key: HBASE-7028
 URL: https://issues.apache.org/jira/browse/HBASE-7028
 Project: HBase
  Issue Type: Task
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Minor
 Attachments: HBASE-7028-0.patch


 Jruby released 1.7.0 which includes InvokeDynamic which speeds lots of things 
 up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-7028) Bump JRuby to 1.7.0

2013-04-09 Thread Elliott Clark (JIRA)


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

Elliott Clark updated HBASE-7028:
-

Attachment: HBASE-7028-1.patch

So not a whole lot of speed but some.  So here's the patch needed for 1.7.3

 Bump JRuby to 1.7.0
 ---

 Key: HBASE-7028
 URL: https://issues.apache.org/jira/browse/HBASE-7028
 Project: HBase
  Issue Type: Task
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Minor
 Attachments: HBASE-7028-0.patch, HBASE-7028-1.patch


 Jruby released 1.7.0 which includes InvokeDynamic which speeds lots of things 
 up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-7028) Bump JRuby to 1.7.3

2013-04-09 Thread Elliott Clark (JIRA)


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

Elliott Clark updated HBASE-7028:
-

Summary: Bump JRuby to 1.7.3  (was: Bump JRuby to 1.7.0)

 Bump JRuby to 1.7.3
 ---

 Key: HBASE-7028
 URL: https://issues.apache.org/jira/browse/HBASE-7028
 Project: HBase
  Issue Type: Task
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Minor
 Attachments: HBASE-7028-0.patch, HBASE-7028-1.patch


 Jruby released 1.7.0 which includes InvokeDynamic which speeds lots of things 
 up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-7028) Bump JRuby to 1.7.3

2013-04-09 Thread Elliott Clark (JIRA)


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

Elliott Clark updated HBASE-7028:
-

Description: Jruby released 1.7.0 which includes InvokeDynamic which should 
speeds lots of things up.  (was: Jruby released 1.7.0 which includes 
InvokeDynamic which speeds lots of things up.)

 Bump JRuby to 1.7.3
 ---

 Key: HBASE-7028
 URL: https://issues.apache.org/jira/browse/HBASE-7028
 Project: HBase
  Issue Type: Task
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Minor
 Attachments: HBASE-7028-0.patch, HBASE-7028-1.patch


 Jruby released 1.7.0 which includes InvokeDynamic which should speeds lots of 
 things up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-7028) Bump JRuby to 1.7.3

2013-04-09 Thread Elliott Clark (JIRA)


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

Elliott Clark updated HBASE-7028:
-

Description: Jruby released 1.7.0 which includes InvokeDynamic which should 
speed lots of things up.  (was: Jruby released 1.7.0 which includes 
InvokeDynamic which should speeds lots of things up.)

 Bump JRuby to 1.7.3
 ---

 Key: HBASE-7028
 URL: https://issues.apache.org/jira/browse/HBASE-7028
 Project: HBase
  Issue Type: Task
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Minor
 Attachments: HBASE-7028-0.patch, HBASE-7028-1.patch


 Jruby released 1.7.0 which includes InvokeDynamic which should speed lots of 
 things up.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-7247) Assignment performances decreased by 50% because of regionserver.OpenRegionHandler#tickleOpening

2013-04-09 Thread Nicolas Liochon (JIRA)

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

Nicolas Liochon updated HBASE-7247:
---

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

Assignment performances decreased by 50% because of
regionserver.OpenRegionHandler#tickleOpening

Key: HBASE-7247
URL: https://issues.apache.org/jira/browse/HBASE-7247
Project: HBase
Issue Type: Improvement
Components: master, Region Assignment, regionserver
Affects Versions: 0.95.2
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
Fix For: 0.98.0, 0.95.1

Attachments: 7247.v1.patch, 7247.v2.patch

The regionserver.OpenRegionHandler#tickleOpening updates the region znode as
Do this so master doesn't timeout this region-in-transition..
However, on the usual test, this makes the assignment time of 1500 regions
goes from 70s to 100s, that is, we're 50% slower because of this.
More generally, ZooKeper commits to disk all the data update, and this takes
time. Using it to provide a keep alive seems overkill. At the very list, it
could be made asynchronous.
I'm not sure how necessary these updates are required (I need to go deeper in
the internal, feedback welcome), but it seems very important to optimize
this... The trival fix would be to make this optional.

[jira] [Updated] (HBASE-8289) TestThreads#testSleepWithoutInterrupt should not expect a bounded wait time

2013-04-09 Thread Nicolas Liochon (JIRA)


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

Nicolas Liochon updated HBASE-8289:
---

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

 TestThreads#testSleepWithoutInterrupt should not expect a bounded wait time
 ---

 Key: HBASE-8289
 URL: https://issues.apache.org/jira/browse/HBASE-8289
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.95.0
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.95.1

 Attachments: 8289.v1.patch


 broke trunk build #4038 (8 avr. 2013 02:21:59) 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-7122) Proper warning message when opening a log file with no entries (idle cluster)

2013-04-09 Thread Jieshan Bean (JIRA)


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

Jieshan Bean commented on HBASE-7122:
-

Yes, HLog is not empty if it closed succesfully. We may not get EOF.
But if we get IOE during close, what will happen? 


 Proper warning message when opening a log file with no entries (idle cluster)
 -

 Key: HBASE-7122
 URL: https://issues.apache.org/jira/browse/HBASE-7122
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 0.94.2
Reporter: Himanshu Vashishtha
Assignee: Himanshu Vashishtha
 Fix For: 0.95.1

 Attachments: HBase-7122-94.patch, HBase-7122-95.patch, 
 HBase-7122.patch, HBASE-7122.v2.patch


 In case the cluster is idle and the log has rolled (offset to 0), 
 replicationSource tries to open the log and gets an EOF exception. This gets 
 printed after every 10 sec until an entry is inserted in it.
 {code}
 2012-11-07 15:47:40,924 DEBUG regionserver.ReplicationSource 
 (ReplicationSource.java:openReader(487)) - Opening log for replication 
 c0315.hal.cloudera.com%2C40020%2C1352324202860.1352327804874 at 0
 2012-11-07 15:47:40,926 WARN  regionserver.ReplicationSource 
 (ReplicationSource.java:openReader(543)) - 1 Got: 
 java.io.EOFException
   at java.io.DataInputStream.readFully(DataInputStream.java:180)
   at java.io.DataInputStream.readFully(DataInputStream.java:152)
   at org.apache.hadoop.io.SequenceFile$Reader.init(SequenceFile.java:1508)
   at 
 org.apache.hadoop.io.SequenceFile$Reader.init(SequenceFile.java:1486)
   at 
 org.apache.hadoop.io.SequenceFile$Reader.init(SequenceFile.java:1475)
   at 
 org.apache.hadoop.io.SequenceFile$Reader.init(SequenceFile.java:1470)
   at 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader$WALReader.init(SequenceFileLogReader.java:55)
   at 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.init(SequenceFileLogReader.java:175)
   at 
 org.apache.hadoop.hbase.regionserver.wal.HLog.getReader(HLog.java:716)
   at 
 org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.openReader(ReplicationSource.java:491)
   at 
 org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.run(ReplicationSource.java:290)
 2012-11-07 15:47:40,927 WARN  regionserver.ReplicationSource 
 (ReplicationSource.java:openReader(547)) - Waited too long for this file, 
 considering dumping
 2012-11-07 15:47:40,927 DEBUG regionserver.ReplicationSource 
 (ReplicationSource.java:sleepForRetries(562)) - Unable to open a reader, 
 sleeping 1000 times 10
 {code}
 We should reduce the log spewing in this case (or some informative message, 
 based on the offset).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-8290) TestHTableMultiplexer is flaky

2013-04-09 Thread Nicolas Liochon (JIRA)


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

Nicolas Liochon updated HBASE-8290:
---

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

 TestHTableMultiplexer is flaky
 --

 Key: HBASE-8290
 URL: https://issues.apache.org/jira/browse/HBASE-8290
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.95.0
Reporter: Nicolas Liochon
Assignee: Nicolas Liochon
 Fix For: 0.98.0, 0.95.1

 Attachments: 8290.v1.patch


 I reproduce it all the time if I comment the sleep here:
 {code}
   private void verifyAllBufferedPutsHaveFlushed(HTableMultiplexerStatus 
 status) {
 int retries = 8;
 int tries = 0;
 do { /*
   try {
 Thread.sleep(2 * TEST_UTIL.getConfiguration().getLong(
   HTableMultiplexer.TABLE_MULTIPLEXER_FLUSH_FREQ_MS, 100));
 tries++;
   } catch (InterruptedException e) {
 Thread.currentThread().interrupt();
   } */
 } while (status.getTotalBufferedCounter() != 0  tries != retries);
 assertEquals(There are still some buffered puts left in the queue,
 0, status.getTotalBufferedCounter());
   }
 {code}
 Given that getTotalBufferedCounter is never decremented, there is a 
 misunderstanding somewhere. As well, reading plain values without a volatile 
 or a synchronized in a MT context is likely to be wrong.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

1 2 3 4 >

1 - 100 of 345 matches

Mail list logo