Hello, I have made some measurements and I think the problem is more serious than poor performance. Many threads are failing to commit or to unlock the row when running my test with 20 threads. However, when tuning what to print and measure, I run twice (or thrice, I'm not sure) and none failed.
The data from these runs are here: http://spreadsheets.google.com/pub?key=rZwAh62-rx3Yvk1W2VtHFUg The numbers are in milliseconds and the negative indicates that the operation was not performed. Thanks, On Fri, May 8, 2009 at 11:35 PM, Ryan Rawson <[email protected]> wrote: > There is no way that this kind of action would ever be performant, with 4 > rpc calls. > > Have a look at the 'atomicIncrement' call... > > -ryan > > > On Fri, May 8, 2009 at 6:57 PM, Guilherme Germoglio <[email protected] > >wrote: > > > thank you, Ryan. > > > > what about changing a row value to something that depends on its previous > > value? An atomic increment of an integer, for example. I'm thinking > > something like the following (in pseudocode - sort of :-): > > > > lock = htable.lockRow(row); > > value = htable.getRow(row, lock); > > value = doSomething(value); > > batchupdate.put(row, column, value); > > htable.commit(batchupdate, lock); > > htable.unlockRow(lock); > > > > On Fri, May 8, 2009 at 8:51 PM, Ryan Rawson <[email protected]> wrote: > > > > > Hey, > > > > > > You can bundle any number of operations (put and delete) to 1 row with > > > BatchUpdate thus obviating the need for using explicit row locks (the > > > server > > > does the locks internally as well, so in this case you are locking > > twice). > > > > > > -ryan > > > > > > On Fri, May 8, 2009 at 4:29 PM, Guilherme Germoglio < > [email protected] > > > >wrote: > > > > > > > Hello, > > > > > > > > I've been running some tests using HTable.lockRow but I think it is > not > > > > performing well. One of my tests is quite simple: run several threads > > > that > > > > will execute the following lines for the same row: > > > > > > > > RowLock rowLock = htable.lockRow(Bytes.toBytes(row)); > > > > htable.commit(batchupdate, rowLock); > > > > htable.unlockRow(rowLock); > > > > > > > > where the batchupdate only does a single "put" on a single column. > > > > > > > > The problem is that it is running very very slow when I use only 20 > > > > threads: > > > > about 30 minutes against the 6~10 seconds of running with 10 threads. > > > Also, > > > > when using 20 threads, some *java.io.IOException: > java.io.IOException: > > > > Invalid row lock* messages are printed. > > > > > > > > Since it is the first time I'm using RowLocks, I'm not sure if the > > > problem > > > > is in my test or in HBase. So, I'm asking you for help. > > > > > > > > I'm using hbase 0.19.2 (rc) in pseudo-distributed mode on a mac book, > > but > > > > the behavior is the same when using 0.19.0. Logs, hbase-site.xml > (which > > > is > > > > the default) and the test can be found on the following link: > > > > > > > > http://germoglio.googlepages.com/logs.zip > > > > > > > > Please notice that although this test doesn't make much sense of > > locking, > > > > the idea is to evolve it in order to perform a few operations besides > > the > > > > only single put between lockRow and unlockRow methods. > > > > > > > > Thank you very much, > > > > > > > > -- > > > > Guilherme > > > > > > > > msn: [email protected] > > > > homepage: http://germoglio.googlepages.com > > > > > > > > > > > > > > > -- > > Guilherme > > > > msn: [email protected] > > homepage: http://germoglio.googlepages.com > > > -- Guilherme msn: [email protected] homepage: http://germoglio.googlepages.com
