[jira] [Created] (ACCUMULO-963) investigate HBase's bucket cache
Eric Newton created ACCUMULO-963: Summary: investigate HBase's bucket cache Key: ACCUMULO-963 URL: https://issues.apache.org/jira/browse/ACCUMULO-963 Project: Accumulo Issue Type: Task Components: tserver Reporter: Eric Newton Assignee: Eric Newton Fix For: 1.6.0 See HBASE-7404. Bucket cache is an improved caching layer that reduces memory fragmentation and stop-the-world java GC. -- 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] (ACCUMULO-956) Iterator to transform key parts
[ https://issues.apache.org/jira/browse/ACCUMULO-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Loss updated ACCUMULO-956: Attachment: key_transforming_iterator-2.patch Updated test based on Keith's comments. Iterator to transform key parts --- Key: ACCUMULO-956 URL: https://issues.apache.org/jira/browse/ACCUMULO-956 Project: Accumulo Issue Type: Improvement Reporter: Brian Loss Fix For: 1.5.0 Attachments: key_transforming_iterator-1.patch, key_transforming_iterator-2.patch, key_transforming_iterator.patch Iterators that transform parts of the key can be tricky if any transformation affects sort ordering. Implement an iterator that takes care of the tricky details that come with modifying sort order (e.g., handling scan-time iterator reconstruction and the associated seek). -- 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] (ACCUMULO-956) Iterator to transform key parts
[ https://issues.apache.org/jira/browse/ACCUMULO-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552868#comment-13552868 ] Brian Loss commented on ACCUMULO-956: - I went ahead and changed it. The code didn't look as bloated as I thought it might :), so the new patch is up. Iterator to transform key parts --- Key: ACCUMULO-956 URL: https://issues.apache.org/jira/browse/ACCUMULO-956 Project: Accumulo Issue Type: Improvement Reporter: Brian Loss Fix For: 1.5.0 Attachments: key_transforming_iterator-1.patch, key_transforming_iterator-2.patch, key_transforming_iterator.patch Iterators that transform parts of the key can be tricky if any transformation affects sort ordering. Implement an iterator that takes care of the tricky details that come with modifying sort order (e.g., handling scan-time iterator reconstruction and the associated seek). -- 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] (ACCUMULO-625) consider augmenting session state with breadcrumbs
[
https://issues.apache.org/jira/browse/ACCUMULO-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552870#comment-13552870
]
An commented on ACCUMULO-625:
-
Currently there's a UniqueColumn map/reduce example
(org.apache.accumulo.examples.simple.mapreduce.UniqueColumns). Ideally I would
like to take that example and turn it into an iterator. Due to the tear up and
tear down factor, is it safe to assume i can only perform this operation per
row bases? So the iterator would find all the distinct column in a single row
and the client would have to perform a final distinct for all the rows?
consider augmenting session state with breadcrumbs
Key: ACCUMULO-625
URL: https://issues.apache.org/jira/browse/ACCUMULO-625
Project: Accumulo
Issue Type: Improvement
Components: tserver
Reporter: Eric Newton
Assignee: Keith Turner
Presently, the iterator stack can be created and destroyed at the whim of the
tserver and its buffering needs. In complex iterations, lower-level
iterators can make significant progress which is not inherently obvious in
any returned key. When the iterator stack is re-created to continue a query,
the last key returned is used to {{seek()}} the iterators. Lower-level
iterators must re-scan their data to move back to the old position.
Consider a mechanism to save progress beyond the last key returned.
--
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] (ACCUMULO-625) consider augmenting session state with breadcrumbs
[
https://issues.apache.org/jira/browse/ACCUMULO-625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552917#comment-13552917
]
Keith Turner commented on ACCUMULO-625:
---
For the unique column case, I think it would be ok if the iterator considered
more than a row. The iterator could drop any key that contains a column it has
seen before. It would start w/ an empty set of seen columns each time its
initialized. The M/R job would still need to do the final unique. The iterator
would just do a lot of filtering. If we supported stateful iterators, then
maybe the 100 most recently seen columns could be maintained in that state
across iterator sessions.
consider augmenting session state with breadcrumbs
Key: ACCUMULO-625
URL: https://issues.apache.org/jira/browse/ACCUMULO-625
Project: Accumulo
Issue Type: Improvement
Components: tserver
Reporter: Eric Newton
Assignee: Keith Turner
Presently, the iterator stack can be created and destroyed at the whim of the
tserver and its buffering needs. In complex iterations, lower-level
iterators can make significant progress which is not inherently obvious in
any returned key. When the iterator stack is re-created to continue a query,
the last key returned is used to {{seek()}} the iterators. Lower-level
iterators must re-scan their data to move back to the old position.
Consider a mechanism to save progress beyond the last key returned.
--
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] (ACCUMULO-956) Iterator to transform key parts
[
https://issues.apache.org/jira/browse/ACCUMULO-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552981#comment-13552981
]
Keith Turner commented on ACCUMULO-956:
---
Code review notes for patch key-transforming-iterator_2.patch.
Notes for KeyTransformingIterator :
* Javadoc should outline why TransformingIter does vis filtering. Someone new
to this may wonder why this iterator is doing that, and why it can't be done by
a follow on iterator. Should also document that you need to configure the
untransformed auths on the scanner and the transformed auths on this iterator.
* javadoc for canSee() is wrong
* transformKeys() is only called when super.hasTop() is true, but it handles
the case when super.hasTop() is false. I was looking to see if this case could
cause a NPE, but then realized it would never occur. Not that anything needs to
be done about this, just something I observed
* For scans if the transformation creates an invalid colvis, this would be
caught. For compactions seems like it would not be caught. May consider
checking that colvis is valid for compactions, do not need to evaluate it, just
ensure it parses. Could use a seperate cache for this. If no auths are passed
for a scan, maybe the transformation is not checked?
* May need to transform column families for seek. Could provide a hook like
the following for the user. Seek would call this hook. There is a bug related
to column qualifiers fetched by the user that are not passed through seek, but
filtered at a lower level. Trying to find the ticket for this. Column
families can still be handled though.
{code:java}
//this function is called by seek to transform column families for seek to
parent iterator
protected CollectionByteSequence columnFamilies
transformColumnFamilies(CollectionByteSequence colFams){
return colFams;
}
{code}
Notes for unit test :
* Need a unit test that transforms to vis a user can see. I think it only
transforms to vis a user can not see.
* Need to test deep copy
* need to test compaction/not scanning
* Is there a test for a range thats before all data and a range thats after
all data?
* Need to test all combinations of range for the following conditions.
Start/end key exist inclusive/exclusive, start/end key not exist (between
existing keys) exclusive/inclusive. I think some of the case are tested, but
not all.
* Need to test seek that passes column families that are transformed.
All of the code looks really nice. For some reason isSetAfterPart() made me
smile.
Iterator to transform key parts
---
Key: ACCUMULO-956
URL: https://issues.apache.org/jira/browse/ACCUMULO-956
Project: Accumulo
Issue Type: Improvement
Reporter: Brian Loss
Fix For: 1.5.0
Attachments: key_transforming_iterator-1.patch,
key_transforming_iterator-2.patch, key_transforming_iterator.patch
Iterators that transform parts of the key can be tricky if any transformation
affects sort ordering. Implement an iterator that takes care of the tricky
details that come with modifying sort order (e.g., handling scan-time
iterator reconstruction and the associated seek).
--
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] [Issue Comment Deleted] (ACCUMULO-962) Failed to do close consistency check for tablet
[
https://issues.apache.org/jira/browse/ACCUMULO-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Newton updated ACCUMULO-962:
-
Comment: was deleted
(was: getFileAndLogEntries() seems to be scanning from prevRow, exclusive, to
metadata entry. In this case:
(7;3dd2f1a9fbe76ce8, 7;3de353f7ced916e4]
Since the previous tablet can split, it will create records in this range, and
the code will throw the error.
I think it should just be scanning [7;3de353f7ced916e4, 7;3de353f7ced916e4]
)
Failed to do close consistency check for tablet
---
Key: ACCUMULO-962
URL: https://issues.apache.org/jira/browse/ACCUMULO-962
Project: Accumulo
Issue Type: Bug
Components: tserver
Affects Versions: 1.5.0
Environment: Small cluster: CentOS 5.7, Cloudera Hadoop 3 update 5
Reporter: Josh Elser
Assignee: Keith Turner
Priority: Minor
After updating Accumulo trunk and deploying to a small cluster, I tend to
find the following table problem is shown on the monitor. It seems to be a
false positive, as I can ignore it and everything goes according to plan.
Some context from the TServer which logged the exception:
{noformat}
2013-01-13 00:39:36,692 [tabletserver.MinorCompactor] DEBUG: Begin minor
compaction /accumulo/tables/7/t-001gnfo/F001gqrl.rf_tmp
7;3de353f7ced916e4;3dd2f1a9fbe76ce8
2013-01-13 00:39:36,713 [tabletserver.TabletServer] DEBUG: Got unloadTablet
message from user: !SYSTEM
2013-01-13 00:39:36,714 [tabletserver.TabletServer] DEBUG: UpSess null 9,549
in 0.153s, at=[0 1 0.01 138] ft=0.103s(pt=0.002s lt=0.051s ct=0.050s)
2013-01-13 00:39:36,714 [tabletserver.TabletServer] DEBUG: Failures: 7, first
extent 7;0f6c8b439581063c;0f5c28f5c28f5c4 successful commits: 0
2013-01-13 00:39:36,714 [tabletserver.TabletServer] DEBUG: Got unloadTablet
message from user: !SYSTEM
2013-01-13 00:39:36,714 [tabletserver.TabletServer] DEBUG: Got unloadTablet
message from user: !SYSTEM
2013-01-13 00:39:36,732 [tabletserver.TabletServer] DEBUG: Got unloadTablet
message from user: !SYSTEM
2013-01-13 00:39:36,782 [tabletserver.TabletServer] DEBUG: UpSess null 4,703
in 0.101s, at=[0 0 0.00 138] ft=0.070s(pt=0.002s lt=0.033s ct=0.035s)
2013-01-13 00:39:36,782 [tabletserver.TabletServer] DEBUG: Failures: 7, first
extent 7;0f6c8b439581063c;0f5c28f5c28f5c4 successful commits: 0
2013-01-13 00:39:36,826 [tabletserver.TabletServer] DEBUG: UpSess null 9,513
in 0.127s, at=[0 0 0.00 138] ft=0.088s(pt=0.003s lt=0.052s ct=0.033s)
2013-01-13 00:39:36,826 [tabletserver.TabletServer] DEBUG: Failures: 7, first
extent 7;0f6c8b439581063c;0f5c28f5c28f5c4 successful commits: 0
2013-01-13 00:39:36,863 [tabletserver.TabletServer] DEBUG: UpSess null 4,688
in 0.071s, at=[0 0 0.00 136] ft=0.048s(pt=0.003s lt=0.022s ct=0.023s)
2013-01-13 00:39:36,863 [tabletserver.TabletServer] DEBUG: Failures: 5, first
extent 7;0f8d4fdf3b645a34;0f7ced916872b038 successful commits: 0
2013-01-13 00:39:36,868 [tabletserver.TabletServer] DEBUG: Got unloadTablet
message from user: !SYSTEM
2013-01-13 00:39:36,868 [tabletserver.TabletServer] DEBUG: Got unloadTablet
message from user: !SYSTEM
2013-01-13 00:39:36,868 [tabletserver.TabletServer] DEBUG: Got unloadTablet
message from user: !SYSTEM
2013-01-13 00:39:36,879 [tabletserver.TabletServer] DEBUG: Got unloadTablet
message from user: !SYSTEM
2013-01-13 00:39:36,886 [tabletserver.Compactor] DEBUG: Compaction
7;3de353f7ced916e4;3dd2f1a9fbe76ce8 25,236 read | 25,236 written | 141,775
entries/sec | 0.178 secs
2013-01-13 00:39:36,888 [tabletserver.Tablet] DEBUG: Logs for memory
compacted: 7;3de353f7ced916e4;3dd2f1a9fbe76ce8
10.10.32.121+9997/ea6c3aab-02ac-4599-b50e-b00df41887ed
2013-01-13 00:39:36,888 [tabletserver.Tablet] DEBUG: Logs for memory
compacted: 7;3de353f7ced916e4;3dd2f1a9fbe76ce8
10.10.32.121+9997/d1aaf814-6209-46f3-8997-36541ea0dcc2
2013-01-13 00:39:36,888 [tabletserver.Tablet] DEBUG: Logs for current memory:
7;3de353f7ced916e4;3dd2f1a9fbe76ce8
10.10.32.121+9997/ea6c3aab-02ac-4599-b50e-b00df41887ed
2013-01-13 00:39:36,895 [log.TabletServerLogger] DEBUG: wrote MinC finish
11312: writeTime:3ms
2013-01-13 00:39:36,895 [tabletserver.Tablet] TABLET_HIST:
7;3de353f7ced916e4;3dd2f1a9fbe76ce8 MinC [memory] - /t-001gnfo/F001gqrl.rf
2013-01-13 00:39:36,895 [tabletserver.Tablet] DEBUG: MinC finish lock 0.00
secs 7;3de353f7ced916e4;3dd2f1a9fbe76ce8
2013-01-13 00:39:36,895 [tabletserver.NativeMap] DEBUG: Deallocating native
map 0x2aaab8f40540
2013-01-13 00:39:36,903 [tabletserver.Tablet] DEBUG:
completeClose(saveState=true completeClose=true)
7;3de353f7ced916e4;3dd2f1a9fbe76ce8
2013-01-13 00:39:36,904 [tabletserver.NativeMap] DEBUG: Allocated native map
0x2aaabc85e210
2013-01-13 00:39:36,904
[jira] [Commented] (ACCUMULO-956) Iterator to transform key parts
[ https://issues.apache.org/jira/browse/ACCUMULO-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552991#comment-13552991 ] Keith Turner commented on ACCUMULO-956: --- It may be necessary to filter based on column family. For example, if colfam C can be transformed to col fam A or B (depending on other parts of the key). If a seek came in for col fam A, then the soruce would be seeked for colfam C. However this could result in transformations to col fam B, which we would want to suppress. Iterator to transform key parts --- Key: ACCUMULO-956 URL: https://issues.apache.org/jira/browse/ACCUMULO-956 Project: Accumulo Issue Type: Improvement Reporter: Brian Loss Fix For: 1.5.0 Attachments: key_transforming_iterator-1.patch, key_transforming_iterator-2.patch, key_transforming_iterator.patch Iterators that transform parts of the key can be tricky if any transformation affects sort ordering. Implement an iterator that takes care of the tricky details that come with modifying sort order (e.g., handling scan-time iterator reconstruction and the associated seek). -- 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] (ACCUMULO-645) Stderr: Warning: $HADOOP_HOME is deprecated
[ https://issues.apache.org/jira/browse/ACCUMULO-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552996#comment-13552996 ] Eric Newton commented on ACCUMULO-645: -- Good catch... I've cleaned that up. Stderr: Warning: $HADOOP_HOME is deprecated --- Key: ACCUMULO-645 URL: https://issues.apache.org/jira/browse/ACCUMULO-645 Project: Accumulo Issue Type: Bug Components: scripts Affects Versions: 1.4.0 Reporter: Eric Newton Assignee: Eric Newton Priority: Trivial Fix For: 1.5.0 Getting tired of looking at the message. -- 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] (ACCUMULO-282) Provides usage examples for client.Flush, client.ReadWriteExample, and client.RowOperations
[
https://issues.apache.org/jira/browse/ACCUMULO-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Newton resolved ACCUMULO-282.
--
Resolution: Fixed
documented how to run the very simple java examples in rev 1433081
Provides usage examples for client.Flush, client.ReadWriteExample, and
client.RowOperations
---
Key: ACCUMULO-282
URL: https://issues.apache.org/jira/browse/ACCUMULO-282
Project: Accumulo
Issue Type: Improvement
Components: docs
Reporter: David Medinets
Assignee: Eric Newton
Priority: Trivial
Fix For: 1.5.0
While these programs are simple, I feel they should still be documented in
one of the readme files. Here are the parameters that each program uses:
{noformat}
bin/accumulo $EXAMPLE_PACKAGE.client.Flush $AINSTANCE $AZOOKEEPERS $AUSER
$APASSWORD $TABLE
bin/accumulo $EXAMPLE_PACKAGE.client.ReadWriteExample -i $AINSTANCE -z
$AZOOKEEPERS -u $AUSER -p $APASSWORD -t $TABLE -s $COLUMN_VISIBILITY --read
bin/accumulo $EXAMPLE_PACKAGE.client.RowOperations $AINSTANCE $AZOOKEEPERS
$AUSER $APASSWORD
{noformat}
--
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] (ACCUMULO-689) No appenders for logger in TransactionWatcherTest
[ https://issues.apache.org/jira/browse/ACCUMULO-689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Newton resolved ACCUMULO-689. -- Resolution: Fixed fixed with revision 1433090. No appenders for logger in TransactionWatcherTest - Key: ACCUMULO-689 URL: https://issues.apache.org/jira/browse/ACCUMULO-689 Project: Accumulo Issue Type: Bug Components: test Environment: Ubuntu Reporter: David Medinets Assignee: Eric Newton Priority: Trivial Fix For: 1.5.0 I ran mvn clean package -P assemble and looked at the output. I noticed the following message: 188 Running org.apache.accumulo.fate.zookeeper.TransactionWatcherTest 189 log4j:WARN No appenders could be found for logger (org.apache.accumulo.fate.zookeeper.TransactionWatcher). 190 log4j:WARN Please initialize the log4j system properly. 191 log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. -- 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] [Created] (ACCUMULO-964) Tserver gets stuck in infinite loop if file missing after compaction
John Vines created ACCUMULO-964: --- Summary: Tserver gets stuck in infinite loop if file missing after compaction Key: ACCUMULO-964 URL: https://issues.apache.org/jira/browse/ACCUMULO-964 Project: Accumulo Issue Type: Bug Components: tserver Affects Versions: 1.4.2, 1.4.1 Reporter: John Vines Assignee: Keith Turner Preface this with I'm not sure if this is something we want to fix, as it's the circumstances of SOMETHING else. Unfortunately, the MapR logs rolled from when it happened, so I can't pinpoint what. And there was nothing in the gc logs. I have several tablet servers stuck minor compacting a tablet. Well, they minor compacted and their at the point of renaming the file, but it fails because the source file isn't there. The code catches the exception, logs the failure, waits a minute, and retries. There is no fail over. It looks like this code is not changed since 1.4.1. -- 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] (ACCUMULO-689) No appenders for logger in TransactionWatcherTest
[ https://issues.apache.org/jira/browse/ACCUMULO-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553096#comment-13553096 ] Hudson commented on ACCUMULO-689: - Integrated in Accumulo-Trunk #636 (See [https://builds.apache.org/job/Accumulo-Trunk/636/]) ACCUMULO-689 provide log4j initialization properties for the unit tests (Revision 1433090) Result = SUCCESS ecn : Files : * /accumulo/trunk/fate/src/test/resources * /accumulo/trunk/fate/src/test/resources/log4j.properties No appenders for logger in TransactionWatcherTest - Key: ACCUMULO-689 URL: https://issues.apache.org/jira/browse/ACCUMULO-689 Project: Accumulo Issue Type: Bug Components: test Environment: Ubuntu Reporter: David Medinets Assignee: Eric Newton Priority: Trivial Fix For: 1.5.0 I ran mvn clean package -P assemble and looked at the output. I noticed the following message: 188 Running org.apache.accumulo.fate.zookeeper.TransactionWatcherTest 189 log4j:WARN No appenders could be found for logger (org.apache.accumulo.fate.zookeeper.TransactionWatcher). 190 log4j:WARN Please initialize the log4j system properly. 191 log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. -- 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] (ACCUMULO-282) Provides usage examples for client.Flush, client.ReadWriteExample, and client.RowOperations
[
https://issues.apache.org/jira/browse/ACCUMULO-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553095#comment-13553095
]
Hudson commented on ACCUMULO-282:
-
Integrated in Accumulo-Trunk #636 (See
[https://builds.apache.org/job/Accumulo-Trunk/636/])
ACCUMULO-282 add in user authorizations so the simple example works simply
(Revision 1433099)
ACCUMULO-282 document the simplest client examples (Revision 1433081)
Result = SUCCESS
ecn :
Files :
*
/accumulo/trunk/examples/simple/src/main/java/org/apache/accumulo/examples/simple/client/ReadWriteExample.java
ecn :
Files :
* /accumulo/trunk/docs/examples/README.client
Provides usage examples for client.Flush, client.ReadWriteExample, and
client.RowOperations
---
Key: ACCUMULO-282
URL: https://issues.apache.org/jira/browse/ACCUMULO-282
Project: Accumulo
Issue Type: Improvement
Components: docs
Reporter: David Medinets
Assignee: Eric Newton
Priority: Trivial
Fix For: 1.5.0
While these programs are simple, I feel they should still be documented in
one of the readme files. Here are the parameters that each program uses:
{noformat}
bin/accumulo $EXAMPLE_PACKAGE.client.Flush $AINSTANCE $AZOOKEEPERS $AUSER
$APASSWORD $TABLE
bin/accumulo $EXAMPLE_PACKAGE.client.ReadWriteExample -i $AINSTANCE -z
$AZOOKEEPERS -u $AUSER -p $APASSWORD -t $TABLE -s $COLUMN_VISIBILITY --read
bin/accumulo $EXAMPLE_PACKAGE.client.RowOperations $AINSTANCE $AZOOKEEPERS
$AUSER $APASSWORD
{noformat}
--
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] (ACCUMULO-645) Stderr: Warning: $HADOOP_HOME is deprecated
[ https://issues.apache.org/jira/browse/ACCUMULO-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553097#comment-13553097 ] Hudson commented on ACCUMULO-645: - Integrated in Accumulo-Trunk #636 (See [https://builds.apache.org/job/Accumulo-Trunk/636/]) ACCUMULO-645 found another HADOOP_HOME reference (Revision 1433102) ACCUMULO-645 found another HADOOP_HOME reference (Revision 1433058) ACCUMULO-645 found and removed many other references to HADOOP_HOME (Revision 1433049) Result = SUCCESS ecn : Files : * /accumulo/trunk/conf/examples/1GB/native-standalone/accumulo-site.xml * /accumulo/trunk/conf/examples/1GB/standalone/accumulo-site.xml * /accumulo/trunk/conf/examples/2GB/native-standalone/accumulo-site.xml * /accumulo/trunk/conf/examples/2GB/standalone/accumulo-site.xml * /accumulo/trunk/conf/examples/3GB/native-standalone/accumulo-site.xml * /accumulo/trunk/conf/examples/3GB/standalone/accumulo-site.xml * /accumulo/trunk/conf/examples/512MB/native-standalone/accumulo-site.xml * /accumulo/trunk/conf/examples/512MB/standalone/accumulo-site.xml ecn : Files : * /accumulo/trunk/start/src/main/java/org/apache/accumulo/start/classloader/AccumuloClassLoader.java ecn : Files : * /accumulo/trunk/bin/accumulo * /accumulo/trunk/bin/bootstrap_hdfs.sh * /accumulo/trunk/bin/config.sh * /accumulo/trunk/start/src/main/java/org/apache/accumulo/start/classloader/AccumuloClassLoader.java * /accumulo/trunk/test/system/auto/TestUtils.py Stderr: Warning: $HADOOP_HOME is deprecated --- Key: ACCUMULO-645 URL: https://issues.apache.org/jira/browse/ACCUMULO-645 Project: Accumulo Issue Type: Bug Components: scripts Affects Versions: 1.4.0 Reporter: Eric Newton Assignee: Eric Newton Priority: Trivial Fix For: 1.5.0 Getting tired of looking at the message. -- 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] (ACCUMULO-340) Failed to find an available server error should halt shell.
[ https://issues.apache.org/jira/browse/ACCUMULO-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Newton updated ACCUMULO-340: - Fix Version/s: (was: 1.5.0) Failed to find an available server error should halt shell. - Key: ACCUMULO-340 URL: https://issues.apache.org/jira/browse/ACCUMULO-340 Project: Accumulo Issue Type: Improvement Reporter: David Medinets Assignee: Eric Newton Priority: Trivial Labels: newbie When the Failed to find an available server message is produced by the 'accumulo shell it seems to repeat endlessly. Can the code be changed to halt so the user does not have to press ^C to kill the process? -- 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] (ACCUMULO-340) Failed to find an available server error should halt shell.
[ https://issues.apache.org/jira/browse/ACCUMULO-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553106#comment-13553106 ] Eric Newton commented on ACCUMULO-340: -- I'm not sure this is worth doing, but adding new forms of getConnector isn't going to happen for 1.5 Failed to find an available server error should halt shell. - Key: ACCUMULO-340 URL: https://issues.apache.org/jira/browse/ACCUMULO-340 Project: Accumulo Issue Type: Improvement Reporter: David Medinets Assignee: Eric Newton Priority: Trivial Labels: newbie When the Failed to find an available server message is produced by the 'accumulo shell it seems to repeat endlessly. Can the code be changed to halt so the user does not have to press ^C to kill the process? -- 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] (ACCUMULO-515) Add utility to pre split table for continuous ingest test
[ https://issues.apache.org/jira/browse/ACCUMULO-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Turner resolved ACCUMULO-515. --- Resolution: Fixed Add utility to pre split table for continuous ingest test - Key: ACCUMULO-515 URL: https://issues.apache.org/jira/browse/ACCUMULO-515 Project: Accumulo Issue Type: Improvement Components: test Reporter: Keith Turner Assignee: Keith Turner Fix For: 1.5.0 -- 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] (ACCUMULO-728) Leaks a BatchScanner thread pool for each BatchDeleter
[ https://issues.apache.org/jira/browse/ACCUMULO-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Turner resolved ACCUMULO-728. --- Resolution: Fixed Fix Version/s: (was: 1.5.0) 1.4.0 Leaks a BatchScanner thread pool for each BatchDeleter -- Key: ACCUMULO-728 URL: https://issues.apache.org/jira/browse/ACCUMULO-728 Project: Accumulo Issue Type: Bug Components: client Affects Versions: 1.3.6, 1.3.5, 1.3.7 Reporter: John Stoneham Assignee: Keith Turner Fix For: 1.4.0 Each BatchDeleter (i.e., TabletServerBatchDeleter) causes a BatchScanner thread to leak. This is because TabletServerBatchDeleter extends TabletServerBatchReader which opens a thread pool on construction but no close() method is offered on the BatchDeleter interface. Workaround: downcast BatchDeleter to either BatchScanner or TabletServerBatchDeleter, then call close(). It appears the close() method is available on BatchDeleter from 1.4 forward, but this still affects 1.3 series users (which is why I'm documenting it). Since BatchDeleter is a one-off class - call delete() and forget - it might make sense for it to close itself instead when complete. -- 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] [Created] (ACCUMULO-965) Zookeeper session ids created as unsigned long, parsed in ZooUtils.java as signed long
Rich Alberth created ACCUMULO-965:
-
Summary: Zookeeper session ids created as unsigned long, parsed in
ZooUtils.java as signed long
Key: ACCUMULO-965
URL: https://issues.apache.org/jira/browse/ACCUMULO-965
Project: Accumulo
Issue Type: Bug
Components: start
Affects Versions: 1.4.2
Environment: Hadoop 0.20, ZooKeeper 3.4.3, CentOS 2.6, x64 CPU, Java
1.6.0_24
Reporter: Rich Alberth
Assignee: John Vines
Seems like this may be a bug. I looked at
LiveTServerSet.assignTablet() it eventually calls Long.toHexString().
The javadoc for toHexString() says the following.
{code}Returns a string representation of the codelong/code
argument as an unsigned integer in base 16.
{code}
However, the method we are using to parse the Long can not handle
unsigned longs greater than MAX_LONG. There does not seem to be a
method in long that can parse the output of toHexString(). For
example the following will fail, any negative number will fail.
{code}Long.parseLong(Long.toHexString(-1), 16);{code}
Original Stack Dump:
{code}
java.lang.NumberFormatException: For input string: b53c3a3610ce0001
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Long.parseLong(Long.java:422)
at
org.apache.accumulo.core.zookeeper.ZooUtil$LockID.init(ZooUtil.java:64)
at
org.apache.accumulo.server.tabletserver.TabletServer$ThriftClientHandler.checkPermission(TabletServer.java:1794)
at
org.apache.accumulo.server.tabletserver.TabletServer$ThriftClientHandler.loadTablet(TabletServer.java:1814)
at
org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor.process(TabletClientService.java:2037)
at
org.apache.accumulo.server.util.TServerUtils$TimedProcessor.process(TServerUtils.java:154)
at
org.apache.thrift.server.TNonblockingServer$FrameBuffer.invoke(TNonblockingServer.java:631)
at
org.apache.accumulo.server.util.TServerUtils$THsHaServer$Invocation.run(TServerUtils.java:202)
{code}
--
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] (ACCUMULO-515) Add utility to pre split table for continuous ingest test
[ https://issues.apache.org/jira/browse/ACCUMULO-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553270#comment-13553270 ] Hudson commented on ACCUMULO-515: - Integrated in Accumulo-Trunk #637 (See [https://builds.apache.org/job/Accumulo-Trunk/637/]) ACCUMULO-515 added min and max parameters to GenSplits (Revision 1433170) Result = SUCCESS kturner : Files : * /accumulo/trunk/server/src/main/java/org/apache/accumulo/server/test/continuous/GenSplits.java Add utility to pre split table for continuous ingest test - Key: ACCUMULO-515 URL: https://issues.apache.org/jira/browse/ACCUMULO-515 Project: Accumulo Issue Type: Improvement Components: test Reporter: Keith Turner Assignee: Keith Turner Fix For: 1.5.0 -- 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] (ACCUMULO-959) compactions starving METADATA table scans
[ https://issues.apache.org/jira/browse/ACCUMULO-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Turner resolved ACCUMULO-959. --- Resolution: Duplicate dup of ACCUMULO-97 compactions starving METADATA table scans - Key: ACCUMULO-959 URL: https://issues.apache.org/jira/browse/ACCUMULO-959 Project: Accumulo Issue Type: Bug Components: tserver Environment: large cluster Reporter: Eric Newton Assignee: Keith Turner Fix For: 1.5.0 A large tablet had many files, and the compaction was taking a long time. During this time, it reserved so many readers that the scan of a metadata tablet on the same host was starved of readers, causing scans to back 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] [Commented] (ACCUMULO-936) Additional debug from r1428556 breaks functional tests
[ https://issues.apache.org/jira/browse/ACCUMULO-936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553330#comment-13553330 ] Dave Marion commented on ACCUMULO-936: -- Is this fixed by ACCUMULO-926? Additional debug from r1428556 breaks functional tests -- Key: ACCUMULO-936 URL: https://issues.apache.org/jira/browse/ACCUMULO-936 Project: Accumulo Issue Type: Sub-task Components: test Reporter: John Vines Assignee: John Vines Fix For: 1.5.0 The output of skipped loading directories breaks the python tests. Either output needs to be squelched for tests or test settings need to be modified to only include necessary folders. -- 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] (ACCUMULO-721) Reloading of lib/ext classloader causes LinkageError
[ https://issues.apache.org/jira/browse/ACCUMULO-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553353#comment-13553353 ] Josh Elser commented on ACCUMULO-721: - Eh, I'm apt to just call it a day with this ticket. I only ever saw it under one extremely specific of circumstances that I don't even recall. It's probably just for the best to close it as can't reproduce and reopen if anyone ever runs into this again. Reloading of lib/ext classloader causes LinkageError Key: ACCUMULO-721 URL: https://issues.apache.org/jira/browse/ACCUMULO-721 Project: Accumulo Issue Type: Bug Components: tserver Reporter: Josh Elser Assignee: Keith Turner Fix For: 1.5.0 Attachments: ACCUMULO-721-classpath, ACCUMULO-721-tserver.debug.log I was writing an iterator that takes advantage of some classes in Google's guava-libraries. I placed my jar and the guava-13.0-rc2.jar into lib/ext. I then ran a simple Java class which opened a Scanner to a table with my customer Iterator in Eclipse. The first attempt succeeded. I then changed my iterator, recompiled the jar, and placed it in lib/ext. The AccumuloClassLoader message said it picked up the changes. Then, trying to run my class in the same manner, I got a java.lang.LinkageError relating to the classloader having two different Class objects for a class defined in the guava jar (which hadn't changed). Moving the guava jar from lib/ext to lib/ and retrying this experiment did not net the same LinkageError. I'll attach full stack traces and the output of `accumulo classpath` -- 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] (ACCUMULO-721) Reloading of lib/ext classloader causes LinkageError
[ https://issues.apache.org/jira/browse/ACCUMULO-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved ACCUMULO-721. - Resolution: Cannot Reproduce Reloading of lib/ext classloader causes LinkageError Key: ACCUMULO-721 URL: https://issues.apache.org/jira/browse/ACCUMULO-721 Project: Accumulo Issue Type: Bug Components: tserver Reporter: Josh Elser Assignee: Keith Turner Fix For: 1.5.0 Attachments: ACCUMULO-721-classpath, ACCUMULO-721-tserver.debug.log I was writing an iterator that takes advantage of some classes in Google's guava-libraries. I placed my jar and the guava-13.0-rc2.jar into lib/ext. I then ran a simple Java class which opened a Scanner to a table with my customer Iterator in Eclipse. The first attempt succeeded. I then changed my iterator, recompiled the jar, and placed it in lib/ext. The AccumuloClassLoader message said it picked up the changes. Then, trying to run my class in the same manner, I got a java.lang.LinkageError relating to the classloader having two different Class objects for a class defined in the guava jar (which hadn't changed). Moving the guava jar from lib/ext to lib/ and retrying this experiment did not net the same LinkageError. I'll attach full stack traces and the output of `accumulo classpath` -- 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] (ACCUMULO-818) User Management API should support appending authorizations
[ https://issues.apache.org/jira/browse/ACCUMULO-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Marion updated ACCUMULO-818: - Status: Patch Available (was: Open) User Management API should support appending authorizations --- Key: ACCUMULO-818 URL: https://issues.apache.org/jira/browse/ACCUMULO-818 Project: Accumulo Issue Type: Improvement Components: client, shell Affects Versions: 1.4.1 Reporter: Mike Drob Assignee: Christopher Tubbs Fix For: 1.5.0 Attachments: ACCUMULO-818-1.patch It would be useful to have a functionality for appending authorizations to a user instead of having to get and set and dealing with potential concurrency issues. -- 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] [Assigned] (ACCUMULO-818) User Management API should support appending authorizations
[ https://issues.apache.org/jira/browse/ACCUMULO-818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned ACCUMULO-818: --- Assignee: Dave Marion (was: Christopher Tubbs) Dave, can you please assign a ticket to yourself when you begin working it? Memory serves that a Jira ticket with an assignee implies that someone is working on it. Thanks! User Management API should support appending authorizations --- Key: ACCUMULO-818 URL: https://issues.apache.org/jira/browse/ACCUMULO-818 Project: Accumulo Issue Type: Improvement Components: client, shell Affects Versions: 1.4.1 Reporter: Mike Drob Assignee: Dave Marion Fix For: 1.5.0 Attachments: ACCUMULO-818-1.patch It would be useful to have a functionality for appending authorizations to a user instead of having to get and set and dealing with potential concurrency issues. -- 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] [Created] (ACCUMULO-966) listscans not showing client address
Keith Turner created ACCUMULO-966: - Summary: listscans not showing client address Key: ACCUMULO-966 URL: https://issues.apache.org/jira/browse/ACCUMULO-966 Project: Accumulo Issue Type: Sub-task Reporter: Keith Turner Assignee: Eric Newton Fix For: 1.5.0 When running listscan in the shell, the client address is showing up as null. I have been tracking this down. Commit 1359639 removed THsHaServer from TServerUtils which was setting the client address. If possible, need to replace this functionality with something that works with thrift 0.9. -- 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] (ACCUMULO-818) User Management API should support appending authorizations
[ https://issues.apache.org/jira/browse/ACCUMULO-818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553422#comment-13553422 ] Dave Marion commented on ACCUMULO-818: -- Josh, Ticket was assigned. I attached the patch so that the assigned could review it, not knowing if the assigned had started working on it or not. Dave User Management API should support appending authorizations --- Key: ACCUMULO-818 URL: https://issues.apache.org/jira/browse/ACCUMULO-818 Project: Accumulo Issue Type: Improvement Components: client, shell Affects Versions: 1.4.1 Reporter: Mike Drob Assignee: Dave Marion Fix For: 1.5.0 Attachments: ACCUMULO-818-1.patch It would be useful to have a functionality for appending authorizations to a user instead of having to get and set and dealing with potential concurrency issues. -- 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
