[jira] [Commented] (ACCUMULO-1444) Single Node Accumulo to start the tracer
[ https://issues.apache.org/jira/browse/ACCUMULO-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14560353#comment-14560353 ] Corey Nolet commented on ACCUMULO-1444: --- My apologies for the late reply. Christopher is correct. On Tue, May 26, 2015 at 5:48 PM, Christopher Tubbs (JIRA) j...@apache.org Single Node Accumulo to start the tracer Key: ACCUMULO-1444 URL: https://issues.apache.org/jira/browse/ACCUMULO-1444 Project: Accumulo Issue Type: Sub-task Components: mini Reporter: Corey J. Nolet Fix For: 1.8.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3549) tablet server location cache may grow too large
[ https://issues.apache.org/jira/browse/ACCUMULO-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14305913#comment-14305913 ] Corey Nolet commented on ACCUMULO-3549: --- So we're comfortable with this change? Should I start cutting RC4? On Wed, Feb 4, 2015 at 3:17 PM, Christopher Tubbs (JIRA) j...@apache.org tablet server location cache may grow too large --- Key: ACCUMULO-3549 URL: https://issues.apache.org/jira/browse/ACCUMULO-3549 Project: Accumulo Issue Type: Bug Components: tserver Reporter: Eric Newton Assignee: Eric Newton Priority: Minor Fix For: 1.6.2, 1.7.0 Time Spent: 50m Remaining Estimate: 0h Now that we're no longer clearing the location cache in the tablet server, it could grow without bound. It should be cleared, either by time, or using an LRU. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-3371) Allow user to set Zookeeper port in MiniAccumuloCluster
[ https://issues.apache.org/jira/browse/ACCUMULO-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14228916#comment-14228916 ] Corey Nolet commented on ACCUMULO-3371: --- David, http://accumulo.apache.org/1.6/apidocs/org/apache/accumulo/minicluster/MiniAccumuloConfig.html I remember adding this in the 1.6 line. Is that not what you were looking for? On Sat, Nov 29, 2014 at 10:32 AM, David Medinets (JIRA) j...@apache.org Allow user to set Zookeeper port in MiniAccumuloCluster --- Key: ACCUMULO-3371 URL: https://issues.apache.org/jira/browse/ACCUMULO-3371 Project: Accumulo Issue Type: Improvement Components: mini Affects Versions: 1.6.1 Environment: Ubuntu inside Docker Reporter: David Medinets Priority: Minor I'm experimenting with Docker to use MiniAccumuloCluster inside containers. However, I ran into an issue that the Zookeeper port is randomly assigned and therefore can't be exposed to the host machine running the Docker container. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-1817) Create a monitoring bridge similar to Hadoop's GangliaContext that can allow easy pluggable support
[ https://issues.apache.org/jira/browse/ACCUMULO-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14224975#comment-14224975 ] Corey Nolet commented on ACCUMULO-1817: --- Awesome! Given that people have been using the jmx wrapper for ganglia metrics, I didn't know if this was still going to be important for others. I can say it's still something I would like to see. Create a monitoring bridge similar to Hadoop's GangliaContext that can allow easy pluggable support --- Key: ACCUMULO-1817 URL: https://issues.apache.org/jira/browse/ACCUMULO-1817 Project: Accumulo Issue Type: New Feature Reporter: Corey J. Nolet Assignee: Billie Rinaldi Labels: proposed Fix For: 1.7.0 We currently expose JMX and it's possible (with external code) to bridge the JMX to solutions like Ganglia. It would be ideal if the integration were native and pluggable. Turns out that Hadoop (hdfs, mapred) and HBase has direct metrics reporting to Ganglia through some nice code provided in Hadoop. Look into the GangliaContext to see if we can implement Ganglia metrics reporting by Accumulo configuration alone. References: http://wiki.apache.org/hadoop/GangliaMetrics, http://hbase.apache.org/metrics.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ACCUMULO-1376) Shell should verify before dropping user
[ https://issues.apache.org/jira/browse/ACCUMULO-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13909411#comment-13909411 ] Corey Nolet commented on ACCUMULO-1376: --- VIncent, Take a look at the Contributors section of the Git WiP[1]. You can download the Eclipse CodeStyle configuration at the bottom of the Source and Guide page [2]. [1] http://accumulo.apache.org/git.html [2] http://accumulo.apache.org/source.html Shell should verify before dropping user Key: ACCUMULO-1376 URL: https://issues.apache.org/jira/browse/ACCUMULO-1376 Project: Accumulo Issue Type: Bug Components: shell Affects Versions: 1.5.0 Reporter: John Vines Assignee: Billie Rinaldi Priority: Trivial Labels: patch Attachments: ACCUMULO-1376.patch The shell checks before you drop a table. It should probably do the same for users. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2178) ColumnFamilyRangeIterator
[ https://issues.apache.org/jira/browse/ACCUMULO-2178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13890624#comment-13890624 ] Corey Nolet commented on ACCUMULO-2178: --- [~vickyeuc], I think the important difference here is the ability to seek directly from the end of one range to the beginning of another. ColumnFamilyRangeIterator - Key: ACCUMULO-2178 URL: https://issues.apache.org/jira/browse/ACCUMULO-2178 Project: Accumulo Issue Type: Improvement Reporter: Corey J. Nolet Priority: Minor It would be extremely useful in situations where you would like to specify a range of rows to iterate and also a range of column families within that range of rows. The current API requires that you specify a start/end key for each row that you will be scanning in the range of column families. There would be a lot gained from the ability to first seek to the beginning column specified in the range of columns, return all keys/values inside of that range, and then seek to the beginning of the range for the following row when the ending column family in the current row has been reached. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ACCUMULO-2177) A scan time iterator to return the first N entries encountered for each row in the input range. (FirstNEntriesInRowIterator)
[ https://issues.apache.org/jira/browse/ACCUMULO-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13868640#comment-13868640 ] Corey Nolet commented on ACCUMULO-2177: --- Agreed. I actually got this working today. I began with the FirstEntryInRowIterator and combined some of the batching from the WholeRowIterator ( providing methods for encoding/decoding the batched rows into the value). A scan time iterator to return the first N entries encountered for each row in the input range. (FirstNEntriesInRowIterator) Key: ACCUMULO-2177 URL: https://issues.apache.org/jira/browse/ACCUMULO-2177 Project: Accumulo Issue Type: Improvement Components: client Reporter: Corey J. Nolet Priority: Minor Labels: iterators I have found this iterator extremely useful when it is important to run a batch scan over a bunch of different ranges but guarantee that a predefined number of results get returned for each row. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
