[jira] [Created] (HBASE-5292) getsize per-CF metric incorrectly counts compaction related reads as well

2012-01-26 Thread Kannan Muthukkaruppan (Created) (JIRA) 
getsize per-CF metric incorrectly counts compaction related reads as well 
--

 Key: HBASE-5292
 URL: https://issues.apache.org/jira/browse/HBASE-5292
 Project: HBase
  Issue Type: Bug
Reporter: Kannan Muthukkaruppan


The per-CF getsize metric's intent was to track bytes returned per-CF. [Note: 
We already have metrics to track # of HFileBlock's read for compaction vs. 
non-compaction cases -- e.g., compactionblockreadcnt vs. fsblockreadcnt.]

However, currently, the metric gets updated for both client initiated Get/Scan 
operations as well for compaction related reads. The metric is updated in 
StoreScanner.java:next() when the Scan query matcher returns an INCLUDE* code 
via a:

 HRegion.incrNumericMetric(this.metricNameGetsize, copyKv.getLength());

We should not do the above in case of compactions.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-5126) AND (USING FilterList) of two ColumnPrefixFilters broken

2012-01-04 Thread Kannan Muthukkaruppan (Created) (JIRA) 
AND (USING FilterList) of two ColumnPrefixFilters broken


 Key: HBASE-5126
 URL: https://issues.apache.org/jira/browse/HBASE-5126
 Project: HBase
  Issue Type: Bug
Reporter: Kannan Muthukkaruppan


[Notice this in 89 branch. Possibly an issue in trunk also.]

A test which does a columnPrefixFilter(tag0) AND columnPrefixFilter(tag1) 
should return 0 kvs; instead it returns kvs with prefix tag0.

{code}
table = HTable.new(conf, tableName)

put = Put.new(Bytes.toBytes(row))
put.add(cf1name, Bytes.toBytes(tag0), Bytes.toBytes(value0))
put.add(cf1name, Bytes.toBytes(tag1), Bytes.toBytes(value1))
put.add(cf1name, Bytes.toBytes(tag2), Bytes.toBytes(value2))

table.put(put)

# Test for AND Two Column Prefix Filters

   
filter1 = ColumnPrefixFilter.new(Bytes.toBytes(tag0));
filter2 = ColumnPrefixFilter.new(Bytes.toBytes(tag2));

filters = FilterList.new(FilterList::Operator::MUST_PASS_ALL);
filters.addFilter(filter1);
filters.addFilter(filter1);

get = Get.new(Bytes.toBytes(row))
get.setFilter(filters)
get.setMaxVersions();
keyValues = table.get(get).raw()

keyValues.each do |keyValue|
  puts Key=#{Bytes.toStringBinary(keyValue.getQualifier())}; 
Value=#{Bytes.toStringBinary(keyValue.getValue())}; 
Timestamp=#{keyValue.getTimestamp()} 
end
{code}

outputs:

{code}
Key=tag0; Value=value0; Timestamp=1325719223523
{code}


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-5104) FilterList doesn't work right with filters (such as ColumPrefixFilter) which use the SEEK_NEXT_USING_HINT

2011-12-29 Thread Kannan Muthukkaruppan (Created) (JIRA) 
FilterList doesn't work right with filters (such as ColumPrefixFilter) which 
use the SEEK_NEXT_USING_HINT
-

 Key: HBASE-5104
 URL: https://issues.apache.org/jira/browse/HBASE-5104
 Project: HBase
  Issue Type: Bug
Reporter: Kannan Muthukkaruppan
Assignee: Madhuwanti Vaidya


Thanks Jiakai Liu for reporting this issue and doing the initial investigation. 
Email from Jiakai below:

Assuming that we have an index column family with the following entries:
tag0:001:thread1
...
tag1:001:thread1
tag1:002:thread2
...
tag1:010:thread10
...
tag2:001:thread1
tag2:005:thread5
...

To get threads with tag1 in range [5, 10), I tried the following code:

ColumnPrefixFilter filter1 = new ColumnPrefixFilter(Bytes.toBytes(tag1));
ColumnPaginationFilter filter2 = new ColumnPaginationFilter(5 /* limit */, 
5 /* offset */);

FilterList filters = new FilterList(Operator.MUST_PASS_ALL);
filters.addFilter(filter1);
filters.addFilter(filter2);

Get get = new Get(USER);
get.addFamily(COLUMN_FAMILY);
get.setMaxVersions(1);
get.setFilter(filters);

Somehow it didn't work as expected. It returned the entries as if the filter1 
were not set.

Turns out the ColumnPrefixFilter returns SEEK_NEXT_USING_HINT in some cases. 
The FilterList filter does not handle this return code properly (treat it as 
INCLUDE).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-4542) add filter info to slow query logging

2011-10-05 Thread Kannan Muthukkaruppan (Created) (JIRA) 
add filter info to slow query logging
-

 Key: HBASE-4542
 URL: https://issues.apache.org/jira/browse/HBASE-4542
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan


Slow query log doesn't report filter in effect.

For example:
{code}
(operationTooSlow): \
{processingtimems:3468,client:10.138.43.206:40035,timeRange: 
[0,9223372036854775807],\
starttimems:1317772005821,responsesize:42411, \
class:HRegionServer,table:myTable,families:{CF1:ALL]},\
row:6c3b8efa132f0219b7621ed1e5c8c70b,queuetimems:0,\
method:get,totalColumns:1,maxVersions:1,storeLimit:-1}
{code}

the above would suggest that all columns of myTable:CF1 are being requested for 
the given row. But in reality there could be filters in effect (such as 
ColumnPrefixFilter, ColumnRangeFilter, TimestampsFilter() etc.). We should 
enhance the slow query log to capture  report this information.



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira