Re: [DISCUSS] Time for 1.7.1?

I triaged tickets on 1.7.1 over Xmas (along with 1.6.5 for that matter). JIRA should be the list of what needs to happen. I've been working on automating CI, too, otherwise I'd probably have an RC already put up. Christopher wrote: I think 1.6.5 and 1.7.1 are both ready to get released. I

Benchmark project on region location caching from HBase

(apparently this is my thing now -- post interesting snippets from other projects) https://github.com/elliottneilclark/benchmark-hbase-cache tl;dr hbase friends found that using a COW-Map implementation was a good fit for performance (over Concurrent* data structures). A glance shows us

Re: could not start the service

See http://accumulo.apache.org/1.7/accumulo_user_manual.html#_cluster_specification and http://accumulo.apache.org/1.7/accumulo_user_manual.html#_hostnames_in_configuration_files Accumulo expects the following files ("masters", "monitor", "tracers", and "slaves") to be present in

Fwd: [announce] thrift-tools

ICYMI Original Message Subject: [announce] thrift-tools Date: Thu, 28 Jan 2016 19:43:47 -0800 From: Raúl Gutiérrez Segalés Reply-To: u...@thrift.apache.org To: u...@thrift.apache.org Hi, Given I've seen a few threads about debugging Thrift messages,

Re: Automating deploy+testing

Deploy has changed a lot since I wrote fats). I will take a look at what you did. https://github.com/keith-turner/fats On Tue, Jan 26, 2016 at 12:38 AM, Josh Elser<josh.el...@gmail.com> wrote: FYI, my evening hack plans this week are going to be centered around creating some automation

Re: Automating deploy+testing

/AccStack/blob/master/setup.bash Cheers, Dylan On Mon, Jan 25, 2016 at 9:38 PM, Josh Elser<josh.el...@gmail.com> wrote: FYI, my evening hack plans this week are going to be centered around creating some automation around building Accumulo, installing it on some nodes and then automatically r

Automating deploy+testing

FYI, my evening hack plans this week are going to be centered around creating some automation around building Accumulo, installing it on some nodes and then automatically running Continuous Ingest/Randomwalk. Looking back now, I can't hardly believe I'e gone this long without writing

Re: Interesting bug report

I've long be waffling about the usefulness of our "infinite retry" logic. It's great for daemons. It sucks for humans. Maybe there's a story in addressing this via ClientConfiguration -- let the user tell us the policy they want to follow. John Vines wrote: Of course, it's when I hit send

Re: question on data block cache

z11373 wrote: Thanks Josh! Ok, here I add column Hosted Tablets and Entries to the table below for additional information. As we can see the tablets are distributed evenly to all tablet servers, and the one with highest load has the highest number of entries (> 1B), there are few tablet servers

Re: question on data block cache

A max of 16 but only 8 running is peculiar. It could be a scheduling thing, but I'm not entirely sure. Do you see this case regularly? (not the one you replied with later and I responded about already) z11373 wrote: Thanks Josh! Another question came to my mind while observing the Monitor UI

Re: question on data block cache

A Tablet is hosted by one and only one TabletServer at any time. The only data you are querying is in Tablet(s) hosted by that one TabletServer. Add more splits to the table which you are heavily querying to spread the load across many TabletServers. Load is parallelized in Accumulo by

Re: question on data block cache

Patches welcome for trace-level block cache logging improvements :) We don't have a lot of granular insight into the block cache. This would be nice. z11373 wrote: Hi Eric, I actually care less about that, at least for now. Is there something simpler, like Accumulo telling the LRU data in

Re: Fixing bugs

Hi Naveen, Thanks for your interest. Find an issue on JIRA[1] which is unassigned and unresolved, and leave a comment that you'd like to work on it. One of the committer can then assign the issue to you. You can either submit a patch[2] or a PullRequest on Github[3]. We're happy for any

Re: Setting Up Environment

Hi Naveen, Can you be more specific on what exactly you mean by environment? Are you talking about how you write code or running Accumulo in general? The former, check the website[1]. The latter, there are numerous ways to install Hadoop and ZooKeeper. Many major "vendors" provide virtual

Re: Request to enable new PreCommit job

Thanks, Jake! Jake Farrell wrote: ACCUMULO has now been added to the pre commit filter, the jenkins job will start getting kicked off when the patch-available flag is set on your tickets -Jake On Sun, Jan 10, 2016 at 1:47 PM, Josh Elser<josh.el...@gmail.com> wrote: Hiya -- I'm

list unsubscribing (was Re: [DISCUSS] Enable PreCommit build)

You unsubscribe yourself from lists just as you subscribed yourself in the first place: http://accumulo.apache.org/mailing_list.html Chris Rigano wrote: Please drop me from this list.

Re: [DISCUSS] Enable PreCommit build

an 8, 2016 at 12:24 PM, Josh Elser<josh.el...@gmail.com> wrote: Hi, Per the other thread "Yetus Accumulo 'Personality'" [1], I'd like to see what people think about turning this on by default. I've been talking to Sean in chat today who had made a suggestion that we get our o

Re: offload request to another tserver

z11373 wrote: I recall that I ever read somewhere that Accumulo is able to move tablets to other tservers if it experiences high load (i.e. read request) on one particular tserver, is that correct? No, we don't rebalance tablet assignments on load. I believe the default balancer

[DISCUSS] Enable PreCommit build

Hi, Per the other thread "Yetus Accumulo 'Personality'" [1], I'd like to see what people think about turning this on by default. I've been talking to Sean in chat today who had made a suggestion that we get our own JIRA acct instead of the "Hadoop QA" user. Aside from that, I'm pretty happy

Re: [DISCUSS] Trivial changes and git

I think I disagree that they are a lot of work or a big distraction. The amount of work behind a trivial change (in terms of the tool: git) is no different (you commit to all active branches and maybe fix merge conflicts). Personally, I find little nit-picky things good to just piggy-back on

Re: Yetus Accumulo "Personality"

Welp: https://issues.apache.org/jira/browse/ACCUMULO-4095?focusedCommentId=15088814=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15088814 Josh Elser wrote: That's a good question (about a point which I haven't outlined as a possibility). I had been poking around

Re: Yetus Accumulo "Personality"

or not. -Sean On Tue, Jan 5, 2016 at 12:00 AM, Josh Elser<josh.el...@gmail.com> wrote: FYI https://issues.apache.org/jira/browse/YETUS-263 was merged in last week. Eric had also sent me a reply off-list which asked if it would be possible to do a `mvn verify -Psunny` to run the small set of

Re: Accumulo-1.6 - Build # 931 - Still Failing

Thank you! Christopher wrote: Fixed in 288a2e108e1a3a3f0cd3bb083c77c56bec97bf08 On Fri, Jan 1, 2016 at 9:36 PM Josh Elser<josh.el...@gmail.com> wrote: Doesn't seem like pulling back the plugin version worked. Will have to look into this more later. On Dec 31, 2015 1:24 AM, "

Re: Yetus Accumulo "Personality"

or not these integration tests were invoked. I also commented with some output on Matt's patch from ACCUMULO-2493 -- I found it rather pleasant to run a single command and get a nice summary of his changes. Josh Elser wrote: For those interested in following along with the PreCommit work, see https

Re: Off-Heap Caches

It should be pretty pluggable, actually. Our current on heap implementation is actually taken from HBase. I think that their bucket cache library is currently the recommended means for offheap. I would be excited to see this done and would be happy to try to help out where possible. On Jan 3,

Re: Accumulo-1.6 - Build # 931 - Still Failing

Doesn't seem like pulling back the plugin version worked. Will have to look into this more later. On Dec 31, 2015 1:24 AM, "Josh Elser" <josh.el...@gmail.com> wrote: > > https://git1-us-west.apache.org/repos/asf?p=accumulo.git;a=commit;h=401350f08807a7544d31e42ce6cc297ab

Re: Accumulo-1.6 - Build # 931 - Still Failing

Ah! This came in via ACCUMULO-4089 that Christopher did. I will make the change. Josh Elser wrote: Oh, is because we're actually using JDK6, whereas most of us are just using JDK7 or 8 but a target of 6? That would jive with what I'm seeing, I think. Christopher wrote: Dropping it to 2.13

Yetus Accumulo "Personality"

For those interested in following along with the PreCommit work, see https://issues.apache.org/jira/browse/YETUS-263 A "personality", in Yetus parlance, defines the the tests/checks that PreCommit will run against Accumulo. For us, it's pretty simple. The personality I provided on YETUS-263

1.6.5 and 1.7.1

Open Issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20ACCUMULO%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20in%20%281.6.5%2C%201.7.1%29%20ORDER%20BY%20assignee%20ASC I cleaned up a number of issues tonight. There are a few open (I've pinged on the ones I am

Re: Accumulo-1.6 - Build # 931 - Still Failing

;ke...@deenlo.com> wrote: On Mon, Dec 28, 2015 at 3:39 PM, Josh Elser<josh.el...@gmail.com> wrote: Was looking at this failure and saw: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.15:check (check-style) on project accumulo-project: Execution check-s

Fwd: Accumulo-1.6 - Build # 931 - Still Failing

Was looking at this failure and saw: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-checkstyle-plugin:2.15:check (check-style) on project accumulo-project: Execution check-style of goal org.apache.maven.plugins:maven-checkstyle-plugin:2.15:check failed: An API incompatibility

Re: State of our RPCs

Well, this doesn't seem to have gone anywhere. Oh well. For those who are still interested: https://issues.apache.org/jira/browse/THRIFT-3479 Josh Elser wrote: (replying to myself since this was a common sentiment) I want to be clear that I am most definitely _not_ advocating that we rip

Fwd: Re: Trigger for Accumulo table

otify an external system when a row is updated. On Wed, Dec 2, 2015, 22:54 Josh Elser <josh.el...@gmail.com <mailto:josh.el...@gmail.com>> wrote: oops :)

Re: State of our RPCs

for the basis of the decision and if its time to revisit. I'm totally ok with a 'no' answer. - Original Message - From: "Josh Elser"<josh.el...@gmail.com> To: dev@accumulo.apache.org Sent: Tuesday, December 1, 2015 2:36:18 PM Subject: Re: State of our RPCs To play devil

Re: State of our RPCs

. Josh Elser wrote: Hi -- My adventures in Thrift as a part of ACCUMULO-4065 are finally coming to a close, it seems. The briefest summary I can give is that our hack to work around an 0.9.0->0.9.1 compatibility issue ended up creating a bug in a very obtuse case (when a server answering a one

Re: State of our RPCs

be revisited? - Original Message - From: "Josh Elser"<josh.el...@gmail.com> To: "dev"<dev@accumulo.apache.org> Sent: Tuesday, December 1, 2015 12:49:26 PM Subject: State of our RPCs Hi -- My adventures in Thrift as a part of ACCUMULO-4065 are finally coming to

Re: State of our RPCs

provide pros and cons for that limited set of protocols? On Tue, Dec 1, 2015 at 1:02 PM,<dlmar...@comcast.net> wrote: What was it about Thrift that drove us to use it? Was it the bindings for multiple languages? Should this decision be revisited? - Original Message - From: "

Re: State of our RPCs

At a glance, it looks like this doesn't provide any transport, just the marshaling of data. I really don't want to own that logic (for example, I've seen the thousands of lines of code in HBase just for setting up their RPC server). John R. Frank wrote: It might be worth considering CBOR

Re: Typo in Accumulo v1.7 documentation

Hi Kent, Thanks for letting us know. You're more than welcome to create an issue on JIRA [1] for Accumulo for documentation. As always, we're even happier to get a patch to fix it too :). The usermanual can be found in the docs/ directory [2]. We probably have the typo in all actively

Re: hasNext throws weird exception

These things happen :) z11373 wrote: Found out the issue, my bad :-( -- View this message in context: http://apache-accumulo.1065345.n5.nabble.com/hasNext-throws-weird-exception-tp15586p15587.html Sent from the Developers mailing list archive at Nabble.com.

Re: total table rows

Ick, that's kind of a pain. We should probably have some kind of utility to compute this for you. You'd likely want to treat the row as a byte[] (instead of thinking in terms of characters) and decrement the last byte in the array. We have a static method on Range.followingPrefix(Text) which

Re: data comparison tool

Yep, that's an easy way to check. It can just be slow depending on how much data you have. I tried to write a slightly more parallel approach to verifying this based using a Merkle tree. https://github.com/apache/accumulo/tree/master/test/system/merkle-replication It's a little tricky as

Re: total table rows

stack of FirstEntryInRowIterator + CountingIterator will return the count of rows in each tablet, which can then be combined on the client side. On Mon, Nov 9, 2015 at 10:25 AM, Josh Elser<josh.el...@gmail.com> wrote: Yeah, there's no explicit tracking of all rows in Accumulo,

Re: total table rows

Yeah, there's no explicit tracking of all rows in Accumulo, you're stuck with enumerating them (or explicitly tracking them yourself at ingest time). The easiest approach you can take is probably using the FirstEntryInRowIterator and counting each row on the client-side. You could do another

Re: total table rows

No worries, just getting everyone on the same page :) David Medinets wrote: Shutting up now. :) On Mon, Nov 9, 2015 at 11:06 AM, Josh Elser<josh.el...@gmail.com> wrote: The question was to compute the number of rows, not the number of entries. The metadata table does not track the

Re: [DISCUSS] What to do about encryption at rest?

+1 I think this is the right step. My hunch is that some of the common data access patterns that we have in Accumulo (over HBase) is that the per-colfam encryption isn't quick as common a design pattern as it is for HBase (please tell me I'm wrong if anyone disagrees -- this is mostly a gut

Re: [DISCUSS] What to do about encryption at rest?

HDFS encryption, whose encrypted blocks may not fall on our index boundaries. If this is a small difference, it might still be worth it for convenience and simpler maintenance, but I suspect the difference will be somewhat substantial. On Thu, Nov 5, 2015 at 12:11 PM Josh

Re: [DISCUSS] What to do about encryption at rest?

Josef Roehrl - PHEMI wrote: Thanks for exposing the issues on this. I had equated 'stale' with incomplete, but I was missing the point entirely. In this case, 'stale' equates to complete, working and stable (but not changing). (pedantically) minus the intermediate-WAL recovery files not

Re: [DISCUSS] What to do about encryption at rest?

William Slacum wrote: So I've been looking into options for providing encryption at rest, and it seems like what Accumulo has is abandonware from a project perspective. There is no official documentation on how to perform encryption at rest, and the best information from its status comes from

Re: tablet split

IIRC, either half of a split tablet will remain on the same node as the parent; however the next invocation of the configured balancer might move them per its policy. z11373 wrote: As my understanding, Accumulo will have data already sorted with row id, and if the number of rows is growing,

Problems with maven-java-formatter-plugin causing master builds to fail.

It seems like the current version of maven-java-formatter-plugin that we depend on is adding in trailing whitespace to fate/**/ZooCache.java which is then causing the checkstyle verification to fail the build. An example:

Re: Problems with maven-java-formatter-plugin causing master builds to fail.

could switch to // comments or remove the blank line. On Sun, Oct 18, 2015, 18:06 Josh Elser<josh.el...@gmail.com> wrote: It seems like the current version of maven-java-formatter-plugin that we depend on is adding in trailing whitespace to fate/**/ZooCache.java which is then causing th

Re: accumulo framework for mesos

Thanks for sharing, Jim. Think it's in a state to mention on http://accumulo.apache.org/projects.html? If so, want to send a small blurb to include on the page? Jim Klucar wrote: Hey accumulo-mesos is a framework for running Accumulo on top of a Mesos cluster. (or having several Accumulo

Re: [ANNOUNCE] Apache Accumulo 1.6.4 released

the mailing list in future. Please try to understand and unsubscribe me. On Thu, Oct 8, 2015 at 1:14 AM, Josh Elser <els...@apache.org <mailto:els...@apache.org>> wrote: The Apache Accumulo project is happy to announce its 1.6.4 release. Version 1.6.4 is the most recent bug-fix re

Re: another question on summing combiner

If you were doing a batch job to just recompute the stats, I'd probably make a new table and then rename it, replacing your old stats table. This can also be problematic in making sure clients that are still writing data will correctly write to the new table. Can you quiesce ingest

Re: new committers!

Billie Rinaldi wrote: Join me in welcoming Dylan Hutchison and Russ Weeks as new Apache Accumulo committers and PMC members! Dylan and Russ, feel free to tell us about yourselves and your development interests. Billie Yay! Congrats and welcome, Dylan and Russ!

[ANNOUNCE] Apache Accumulo 1.6.4 released

The Apache Accumulo project is happy to announce its 1.6.4 release. Version 1.6.4 is the most recent bug-fix release in its 1.6.x release line. This version includes a fix for a data-loss bug over previous versions in addition to other bug fixes. Existing users of the 1.6.x release line are

Re: How to best measure how the lack of data-locality affects query performance

Jeff Kubina wrote: Per my thread "How does Accumulo process r-files for bulk ingesting?" on the user@ list I would like to test/measure how a lack of data-locality of bulk ingested files effects query performance. I seek comments/suggestions on the outline of the design for the test: Outline:

Re: scan command hung

z11373 wrote: Thanks Billie/Josh! That's indeed fixing the issue, the scan now returns instantly!! So when we scan the whole table and filtering by column family, Accumulo still has to go through all rows (ordered by the key), and check if the particular item has specific column family, and

Re: scan command hung

Yup that's exactly what my hunch was. You can try configuring a locality group for your "slow" column families, compact the table and then rerun your scans. They should be fast after you do this. On Oct 5, 2015 11:25 AM, "z11373" wrote: > Hi Josh, > I see there are 4 tablet

No Javadocs in 1.6.4 bin tarball

While updating the website, I noticed that the 1.6.4 bin tarball doesn't contain pre-built javadocs like 1.5.4 did. My memory doesn't recall if this was an intentional change or something that just fell through the cracks. Does anyone remember?

Re: No Javadocs in 1.6.4 bin tarball

Okie doke. I will update the release guidelines to make sure this is explicit. Thanks! Christopher wrote: This was an intentional change with 1.6.x On Sat, Oct 3, 2015, 16:56 Josh Elser<josh.el...@gmail.com> wrote: While updating the website, I noticed that the 1.6.4 bin tarball d

[RESULT] [VOTE] Accumulo 1.6.4-rc1

This vote passes with 4 +1s and nothing else. Thanks to all who took the time to evaluate the RC. - Josh Josh Elser wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.6.4. Git Commit: edba4f4ca95d9e8ec0299a631234e5c9a319f9ec Branch: 1.6.4-rc1 If this vote

Re: scan command hung

I'm wondering if the distribution of your few columns across the actual rfiles has an impact. I believe it could be that, even without column families, a subset of the rfiles could be precluded from even being opened (because we know your given column family doesn't exist in the file). So,

Re: scan command hung

Ignoring the prerequisite: "are HDFS, ZooKeeper and Accumulo all running properly to the best of your knowledge"... What does you table look like? How many rows? How many columns per row? Are the number of columns per row fixed or varied? Do you have any locality groups configured? Have you

[VOTE] Accumulo 1.6.4-rc1

Accumulo Developers, Please consider the following candidate for Accumulo 1.6.4. Git Commit: edba4f4ca95d9e8ec0299a631234e5c9a319f9ec Branch: 1.6.4-rc1 If this vote passes, a gpg-signed tag will be created using: git tag -f -m 'Apache Accumulo 1.6.4' -s 1.6.4

Re: [ANNOUNCE] Apache Gora 0.6.1 Release

? It should be updated to use the ClientContext stuff. -Eric On Tue, Sep 15, 2015 at 11:12 AM, Josh Elser<els...@apache.org> wrote: Oy, we need to update their dependency... Also, another project which would be good to add to Christopher's rc-verify. Original Message S

FYI: 1.5 branch deleted (again)

Should be finally done with this branch. Don't forget to run `git fetch --prune` and try not to re-push it, please :) Original Message Subject: Git Push Summary Date: Sat, 26 Sep 2015 21:07:34 + (UTC) From: els...@apache.org Reply-To: dev@accumulo.apache.org To:

Re: [ADVISORY] Possible data loss during HDFS decommissioning

What kind of documentation can we put in the user manual about this? Recommend to only decom one rack at a time until we get the issue sorted out in Hadoop-land? dlmar...@comcast.net wrote: BLUF: There exists the possibility of data loss when performing DataNode decommissioning with Accumulo

Re: [ADVISORY] Possible data loss during HDFS decommissioning

. *From: *"Josh Elser" <josh.el...@gmail.com> *To: *dev@accumulo.apache.org *Cc: *u...@accumulo.apache.org *Sent: *Wednesday, September 23, 2015 10:26:50 AM *Subject: *Re: [ADVISORY] Possible data loss during HDFS decommissi

[ANNOUNCE] Apache Accumulo 1.5.4 released

The Apache Accumulo project is happy to announce its 1.5.4 release. Version 1.5.4 is the most recent bug-fix release in its 1.5.x release line. This version includes a fix for a data-loss bug over previous versions in addition to other minor bug fixes. Existing users of 1.5.x are encouraged to

Time for 1.6.4

(pushing on maintenance releases to counteract blowback from the bulk-load bug) Anyone want to take this on now that 1.5.4 is out of the door? It will require an audit of the 1.5.4 L changes that we made to ensure that nothing have changed and that the merges happened as expected, but I am

Re: [VOTE] Accumulo 1.5.4-rc2

1.5.4-rc2 passes as Apache Accumulo 1.5.4 with five +1's and one -0. I'll work on promoting the artifacts as time permits. Josh Elser wrote: Forgot to explicitly include my +1 (with ACCUMULO-4003 ack'ed) Josh Elser wrote: Accumulo Developers, Please consider the following candidate

Re: [VOTE] Accumulo 1.5.4-rc2

Forgot to explicitly include my +1 (with ACCUMULO-4003 ack'ed) Josh Elser wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.5.4. Git Commit: 151db23e7d95cf77c08023ee18b7e524f78286fc Branch: 1.5.4-rc2 If this vote passes, a gpg-signed tag will be created using

Docs on verifying releases

Given the recent spate of licensing blunders and a question by Ed Coleman, I made some time earlier this week to write out obligations for verifying releases on the website. http://accumulo.staging.apache.org/verifying_releases.html Reviews/feedback is welcome as always. Please feel free to

Re: [VOTE] Accumulo 1.5.4-rc2

Relatively quiet on this RC so far. ~1 day left on this one. Make sure to double check the licenses (that's all that's changed here over rc1) and cast your vote. Thanks. Josh Elser wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.5.4. Git Commit

Re: Docs on verifying releases

ed? On Thu, Sep 17, 2015 at 12:20 PM, Mike Drob<md...@mdrob.com> wrote: Typo: "While a release of _and_ Apache project" On Thu, Sep 17, 2015 at 12:13 PM, Josh Elser<josh.el...@gmail.com> wrote: Given the recent spate of licensing blunders and a question by Ed Colema

Re: Docs on verifying releases

sort of consensus is all I'm looking for, lazy or not). Josh Elser wrote: Ah yes, I did forget to aggregate the various pages and include them. I meant to do so. Thanks for the feedback so far, all. Sean Busbey wrote: links to the foundation guidelines we're providing application guidance

Request for help on Bigtop integration

Sean Mackrory has staged some changes to Bigtop which add Accumulo support to the project. Sadly, for his own reasons, he's not planning to finish this integration, which involves adding tests and keep a watchful eye over it as time passes.

Re: sync datacenter

I believe one lurking problem would be Scanners/BatchScanners/BatchWriters (and maybe other things reading and writing data) wouldn't notice the table name swap. Accumulo presents the "human readable" name for users, but internally references things by "table id" (see `tables -l` in the

Re: [VOTE] Accumulo 1.5.4-rc1

in ACCUMULO-3988 On Sat, Sep 5, 2015 at 4:27 PM, Josh Elser<els...@apache.org> wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.5.4. Git Commit: 12a1041dcbb7f3b10543c305f27ece4b0d65ab9c Branch: 1.5.4-rc1 If this vote passes, a gpg-sign

Re: [VOTE] Accumulo 1.5.4-rc1

license fixes in 1.6.x and later, as applicable. On Thu, Sep 10, 2015 at 12:28 PM Josh Elser<els...@apache.org> wrote: Thanks again for taking the time to inspect things so thoroughly, Sean. Others who have already voted, I'd ask for your opinion on whether we should sink this release

Re: [VOTE] Accumulo 1.5.4-rc1

le. On Thu, Sep 10, 2015 at 12:28 PM Josh Elser<els...@apache.org> wrote: Thanks again for taking the time to inspect things so thoroughly, Sean. Others who have already voted, I'd ask for your opinion on whether we should sink this release (instead of me blindly going by majori

Re: [VOTE] Accumulo 1.5.4-rc1

Sean Busbey wrote: We can't tie the ability to vote -1 on a release to volunteering to fix the issue that causes a -1. Presuming a release is valued by the community, the work will get done. At the same time, it is crappy for Josh to be expected to fix everything, especially if he doesn't

[RESULT] [VOTE] Accumulo 1.5.4-rc1

RC1 has failed due to licensing concerns. Josh Elser wrote: Also, a heads-up since I had one question about this already: you (hopefully) will notice that this was signed using a different key than previously for me. This is expected. I built this release on a virtual server (under my virtual

Re: [VOTE] Accumulo 1.5.4-rc1

Sean Busbey wrote: > So let's deal with the matter of the vote at hand first. After that we can >> deal with fixing things, hopefully with Josh abstaining. (Josh I'd >> recommend un-assigning yourself from the issue if you'd prefer someone >> else >> take it up.) >> >> > I'll likely make

Re: [VOTE] Accumulo 1.5.4-rc1

x Moundalexis<al...@cloudera.com> wrote: -1 (non-binding) Fix now and it'll be fixed here and in 1.6.x. On Thu, Sep 10, 2015 at 2:46 AM, Sean Busbey<bus...@cloudera.com> wrote: -1 * signatures check out * checksums match * licensing errors noted in ACCUMULO-3988 On Sat, Sep 5, 2

Re: [VOTE] Accumulo 1.5.4-rc1

Christopher wrote: The larger concern I have is that expecting it to be fixed prior to 1.5.4 might mean loss of willingness to create an RC2 for 1.5.4 and release it at all. Recall, the 1.5 branch was only revived at all to fix some critical issues and move on. It's still a viable alternative to

Re: [VOTE] Accumulo 1.5.4-rc1

om> wrote: -1 (non-binding) Fix now and it'll be fixed here and in 1.6.x. On Thu, Sep 10, 2015 at 2:46 AM, Sean Busbey<bus...@cloudera.com> wrote: -1 * signatures check out * checksums match * licensing errors noted in ACCUMULO-3988 On Sat, Sep 5, 2015 at 4:27 PM, Josh Elser<els..

Re: sync datacenter

If you already have the data in one datacenter, ExportTable and ImportTable are the way to go. http://accumulo.apache.org/1.7/examples/export.html If you have new data to write to multiple locations, you might consider trying out the data center replication feature in 1.7.0.

Re: sync datacenter

The Import/Export route won't have any downtime on the "source" system. You can clone the source table, and use that to run the export. On the "destination" system, yes, you will only have the data since the last import. One thing I didn't think about before is that I'm not sure you can

Re: [VOTE] Accumulo 1.5.4-rc1

comfortable placing my existing private key on this server and created a new one instead. You'll want to recv-keys on my new key when verifying checksums: `gpg --keyserver pgp.mit.edu --recv-keys AB471AE9` Josh Elser wrote: Accumulo Developers, Please consider the following candidate for Accumulo

[VOTE] Accumulo 1.5.4-rc1

Accumulo Developers, Please consider the following candidate for Accumulo 1.5.4. Git Commit: 12a1041dcbb7f3b10543c305f27ece4b0d65ab9c Branch: 1.5.4-rc1 If this vote passes, a gpg-signed tag will be created using: git tag -f -m 'Apache Accumulo 1.5.4' -s 1.5.4

Re: exception thrown during minor compaction

Keith Turner wrote: > Thanks Eric and Josh. > > There shouldn't be delete marker because my code doesn't perform any delete > operation, right? > > Josh: if that out-of-the-box SummingCombiner cannot handle delete marker, > then I'd think that's bug:-) >

Re: Specify Range for data in specific column family

That's very likely not ever going to happen. Ranges are used for identifying portions of a table to scan. These ranges are identified by start and end keys. Thus, the granularity of Key itself defines what is valid in a Range (e.g. you can start at a row+cf and end at a row+cf+cq). A second

Re: exception thrown during minor compaction

z11373 wrote: Thanks Eric and Josh. There shouldn't be delete marker because my code doesn't perform any delete operation, right? Correct. Josh: if that out-of-the-box SummingCombiner cannot handle delete marker, then I'd think that's bug :-) Yes, definitely. Sounds like that is not the

Re: exception thrown during minor compaction

An empty value seems to imply that you wrote some unexpected data to your table. The following code does work correctly (using 1.7.0). byte[] bytes = new LongLexicoder().encode(1l); System.out.println(Arrays.toString(bytes)); System.out.println(new LongLexicoder().decode(bytes));

Re: exception thrown during minor compaction

Well that's curious. Certainly looks like it's doing the right thing. I wonder if there's an edge case with the Lexicoder that's causing it to write bad data... Pretty much the only thing I can think of that wouldn't require code is the `grep` shell command. I believe the implementation will

Re: Specify Range for data in specific column family

Use `[batch]scanner.fetchColumnFamily(Text)` to specify the column family. All rows would just be specified by `Collections.singleton(new Range())`. - Josh z11373 wrote: Hi, AccumuloInputFormat has setRanges method which takes collection of Range. I want it to process all rows with specific

Re: exception thrown during minor compaction

ful! Eric Newton wrote: Sure, but not during a compaction that does not involve all the underlying files. The delete keys must be propagated. I'm not completely familiar with the underlying libraries that help you write iterators, I just know it's a common mistake. On Mon, Aug 31, 2015 at 11:5

<    1   2   3   4   5   6   7   8   9   10   >