Re: Proposal for splitting ACCUMULO-1242 into subtasks.

+1 LGTM Overall approach looks good, we can deal with details in review. -- Sean On May 12, 2014 8:49 PM, "Mike Drob" wrote: > +1. > > You've spent more time thinking about this than the rest of us combined, > probably, so if you think this is the best approach I recommend just going > for it.

Re: Review Request 21282: ACCUMULO-2791 Downgrade commons-codec to match that provided by Hadoop.

> On May 9, 2014, 9:22 p.m., Mike Drob wrote: > > core/src/main/java/org/apache/accumulo/core/client/mapreduce/lib/impl/InputConfigurator.java, > > line 180 > > > > > > Need to specify UTF8? > > Sean Busbey wrote: >

Re: Accumulo SafeMode

I agree with Arshak. This is a problem of Hadoop not leaving safemode. I had that happen where some of the blocks did not report in. To fix it, I had to forcefully let the namenode leave safemode (hadoop dfsadmin -safemode leave) and then run an fsck to delete missing files. -- View this mess

Re: Accumulo SafeMode

No worries, we all have been there :) On 5/12/14, 9:48 PM, Marko Escriba wrote: Yes, sorry for that. I've found the problem on snapshot itself. Thanks. -- View this message in context: http://apache-accumulo.1065345.n5.nabble.com/Accumulo-SafeMode-tp9746p9792.html Sent from the Developers ma

Re: Accumulo SafeMode

Yes, sorry for that. I've found the problem on snapshot itself. Thanks. -- View this message in context: http://apache-accumulo.1065345.n5.nabble.com/Accumulo-SafeMode-tp9746p9792.html Sent from the Developers mailing list archive at Nabble.com.

Understanding SortedLogRecovery

I have a few questions on about the members on LogFileKey and how they're used to implement (sorted) log recovery. My purpose in asking is related to extracting LogEntryKey/LogEntryValue pairs with LogEvents.MUTATION and LogEvents.MANY_MUTATIONS for a specific table (extent). I'm reading thro

Re: Proposal for splitting ACCUMULO-1242 into subtasks.

+1. You've spent more time thinking about this than the rest of us combined, probably, so if you think this is the best approach I recommend just going for it. If we discover other issues as they crop up, then we can deal with them at that point. Mike On Mon, May 12, 2014 at 9:15 PM, Ed Coleman

RE: Accumulo Monitoring Page Improvements/redesign?

To echo what Josh is saying, I keep hoping to prototype something that would include the metrics library from Coda Hale (http://metrics.codahale.com/) my idea was to pick a component, supplement with Coda Hale's library and a REST api in parallel with the current facilities to see how it plays o

[ANNOUNCE] Apache Accumulo 1.6.0 Release

The Apache Accumulo project is especially pleased to announce its 1.6.0 release. The Apache Accumulo sorted, distributed key/value store is a robust, scalable, high performance data storage system that features cell-based access control and customizable server-side processing. It is based on Goog

Proposal for splitting ACCUMULO-1242 into subtasks.

I am willing to take another run at the Consistent Logging ticket, ACCUMULO-1242, but I'd like to achieve a consensus on an approach before starting. The tl;dr version - I would like to split ACCUMULO-1242 into subtasks. Target version would be 1.7.0 (or whatever it gets called, would not mind d

Re: [DISCUSS] packaging our dependencies

Packaging other jars that had been made available at runtime by virtue of their existence in the Hadoop directories.  I'm only talking about dependencies that were/are provided by Hadoop.  But since you brought up ZooKeeper, my understanding is that ZK intends for dependent projects to only

Re: [DISCUSS] packaging our dependencies

Does that mean package everything else? What about ZooKeeper? -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 12, 2014 at 3:38 PM, Joey Echeverria wrote: > +1 to only depending on Hadoop client jars. > > > -- > Joey Echeverria > Chief Architect > Cloudera Government Solutions

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

On 5/12/14, 11:00 AM, Keith Turner wrote: On Mon, May 12, 2014 at 10:44 AM, Josh Elser wrote: On 5/12/14, 10:41 AM, Keith Turner wrote: On Sun, May 11, 2014 at 6:54 PM, Josh Elser wrote: >SGTM. Looks like there aren't currently any fixes of much substance for 1.6.1 presently, but there

Dealing with rejected Mutations

I remember hearing in passing at least once about the lack of insight into which mutation(s) out of a batch sent to a BatchWriter failed. I checked briefly, but I didn't find any docs that specifically talk about this. Additionally, what are the failure causes? Can I see a MutationsRejectedEx

Re: [DISCUSS] packaging our dependencies

+1 to only depending on Hadoop client jars. -- Joey Echeverria Chief Architect Cloudera Government Solutions On Sun, May 11, 2014 at 6:07 PM, Christopher wrote: > In general, I think this is reasonable... especially because Hadoop > Client stabilizes things a bit. On the other hand, things get

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

Inline. On Mon, May 12, 2014 at 12:00 PM, Sean Busbey wrote: > Overall, I like this plan. Ideally, it'd be best if we could limit our > active branches to major versions and avoid creating major version branches > while we still are waiting on a previous major release's last minor release. > > On

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

The goal here isn't just to insert a mechanical change to the SCM and change the workflow. The goal is to try to orient ourselves to provide faster bugfix deliveries on supported releases, while shifting the focus of active development on major/minor releases. -- Christopher L Tubbs II http://grav

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

Overall, I like this plan. Ideally, it'd be best if we could limit our active branches to major versions and avoid creating major version branches while we still are waiting on a previous major release's last minor release. Once we've fully transitioned to a new versioning scheme, what do we expec

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

The one clarification here is that I don't think we should have a long-lived 1.6.1 branch. For 1.5.2, I think we should plan a 1.5.2 release soon, and then eliminate the long-lived development branch for 1.5.x, in favor of a short-lived 1.5.x bugfix branches that are oriented around specific bugs

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

I think Joey hit the point best: the big change would be the shift to short-lived bugfix branches for immediate release and more regular release cadence, and long-lived branches would be for active development on major/minor releases. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

Presumably, it would be based on the tag being fixed, and may include commits from the next minor release. I'm not sure exactly how that workflow would go. There may be other workflows, but I was thinking something like: 1. Create a bugfix release plan 2. Branch the latest tag being bugfix'ed 3. A

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

Why eliminate the 1.6.1-SNAPSHOT branch for 1.7.0-SNAPSHOT? Why not just branch the master and insert a 1.7.0-SNAPSHOT into our workflow after 1.6.1-SNAPSHOT and before master? On Mon, May 12, 2014 at 11:10 AM, Bill Havanki wrote: > I like this plan overall. I am definitely in favor of more freq

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

I like this plan overall. I am definitely in favor of more frequent, lighter-weight bugfix releases. We can start to move toward a regular schedule of them, based on whether there is enough there to warrant one each month / two months / whatever. We could start by branching off 1.6.0 now, and merg

Re: Accumulo Monitoring Page Improvements/redesign?

Along these lines curious where and how monitor stores its stats currently. I imagine some of it comes from !METADATA but guessing not all of it does (for example the time series). If there was a clean way to access the stats there is no shortage of powerful and pretty monitoring tools. On May 1

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

On Mon, May 12, 2014 at 10:44 AM, Josh Elser wrote: > On 5/12/14, 10:41 AM, Keith Turner wrote: > >> On Sun, May 11, 2014 at 6:54 PM, Josh Elser wrote: >> >> >SGTM. Looks like there aren't currently any fixes of much substance for >>> >1.6.1 presently, but there are a few that would make for a

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

On Sun, May 11, 2014 at 6:15 PM, Christopher wrote: > Accumulo developers: > > As part of our transition to better versioning standards, and more > regular releases, with better release planning, I was thinking that > our development branches should generally reflect an anticipated > minor/major

Re: Accumulo Monitoring Page Improvements/redesign?

Personally, I'm not sold on the ability to integrate with an external tool that will give us adequate functionality as compared to what we presently have with the monitor (someone prove me wrong). It doesn't *have* to be pretty -- the monitor is extremely functional already which is the importa

Re: Accumulo Blog Posts

I tried sending you an invitation, but it appears to be broken at the moment (which I verified on the ASF services status page). We'll have to try again later. On Fri, May 9, 2014 at 7:39 AM, David Medinets wrote: > I think the community decided to move forward with this initiative. And I > thi

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

On 5/12/14, 10:41 AM, Keith Turner wrote: On Sun, May 11, 2014 at 6:54 PM, Josh Elser wrote: >SGTM. Looks like there aren't currently any fixes of much substance for >1.6.1 presently, but there are a few that would make for a very-low impact >1.6.1, and a good 1.5.2 which also includes the fal

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

On Sun, May 11, 2014 at 6:54 PM, Josh Elser wrote: > SGTM. Looks like there aren't currently any fixes of much substance for > 1.6.1 presently, but there are a few that would make for a very-low impact > 1.6.1, and a good 1.5.2 which also includes the fallout tickets shortly > after 1.5.1. Timefr

Re: Accumulo Monitoring Page Improvements/redesign?

One thing that would make integration with existing monitoring systems easier would be to expose our common JMX metrics additionally as simple web interfaces that provide JSON, similar to how other ecosystem projects do. I'd really, really like us to focus on our core project goal. We already have

Re: Accumulo Monitoring Page Improvements/redesign?

Al, There's an existing JIRA for packaging the monitor as a war - https://issues.apache.org/jira/browse/ACCUMULO-1325 - so that is a good place to start. There's also been some discussion about going the other way - instead of building up the monitor we could tear it down and let somebody else ma

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

On Mon, May 12, 2014 at 10:08 AM, Alex Moundalexis wrote: > To confirm, a bug fix release will just cut from whatever specific commit > is selected by the proposer? My read is that if there were issues fixed in 1.7.0-SNAPSHOT that would warrant a 1.6.1 release, then a new branch would be made, th

Re: [DISCUSS] Dev branches reflecting minor/major versions, not bugfixes

Makes sense to me. To confirm, a bug fix release will just cut from whatever specific commit is selected by the proposer? On Sun, May 11, 2014 at 3:15 PM, Christopher wrote: > Accumulo developers: > > As part of our transition to better versioning standards, and more > regular releases, with b

Accumulo Monitoring Page Improvements/redesign?

All, Christopher and I exchanged some ideas during Accumulo Meetup last week about how we can improve Accumulo Monitoring Page... I would like to reach out to the community to flesh out some prototype ideas and to make sure we are not duplication any ongoing efforts that may take place. How do yo

Re: Review Request 21282: ACCUMULO-2791 Downgrade commons-codec to match that provided by Hadoop.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21282/#review42687 --- Ship it! Ship It! - Mike Drob On May 10, 2014, 7:01 a.m., Sean B

Re: Review Request 21072: ACCUMULO-2635 - ZooCacheFactory (1.6.1)

Bumping this review one more time, as my first bump got was engulfed by the ASF email outage. Bill On Wed, May 7, 2014 at 12:56 PM, Bill Havanki wrote: > Just bumping this available review - comments welcome. > > > On Mon, May 5, 2014 at 10:23 AM, Bill Havanki > wrote: > >>This is an autom

Re: Review Request 21169: ACCUMULO-2770 Add utility to read local WAL

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21169/#review42686 --- core/src/main/java/org/apache/accumulo/core/conf/Property.java

Re: Review Request 21169: ACCUMULO-2770 Add utility to read local WAL

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21169/ --- (Updated May 9, 2014, 5:35 p.m.) Review request for accumulo, Sean Busbey and E

Re: Review Request 21282: ACCUMULO-2791 Downgrade commons-codec to match that provided by Hadoop.

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21282/ --- (Updated May 9, 2014, 9:48 p.m.) Review request for accumulo. Changes ---

Re: Review Request 21043: ACCUMULO-1691 Update Thrift to 0.9.1

> On May 9, 2014, 9:19 p.m., Sean Busbey wrote: > > which branch is this targeting? nm. found 1.7.0 on ticket - Sean --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21043/#review42606 ---

Re: Accumulo SafeMode

I believe this is referring to HDFS being in safe mode not Accumulo (there is no such thing). You can see more info if you point your browser to namenode:50070. Hi guys, We have accumulo intances setup on aws. And we have just decided to move it to a new region, so we created snapshots from the

Re: Review Request 21043: ACCUMULO-1691 Update Thrift to 0.9.1

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21043/#review42606 --- which branch is this targeting? - Sean Busbey On May 2, 2014, 11:

Accumulo SafeMode

Hi guys, We have accumulo intances setup on aws. And we have just decided to move it to a new region, so we created snapshots from the current configurations. But when trying to start accumulo i've encountered an issue: 2014-05-12 07:56:19,440 [server.Accumulo] WARN : Waiting for the NameNode to

Re: Review Request 21043: ACCUMULO-1691 Update Thrift to 0.9.1

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21043/#review42607 --- server/base/src/main/java/org/apache/accumulo/server/util/CustomNon