Re: [VOTE] Accumulo 1.7.2-rc2

Christopher wrote: +0 * Verified all hashes, sigs * Unit tests and ITs all pass (org.apache.accumulo.test.BadDeleteMarkersCreatedIT.test timed out the first time, but passed on re-run) * Verified contents of bin tarball match jars in staging repo and src tarball match rc branch in git My

Re: [VOTE] Accumulo 1.7.2-rc2

read the pom on !thrift. On Jun 19, 2016 9:26 PM, "Josh Elser"<els...@apache.org> wrote: -1 (binding) HTrace's NOTICE is missing in -bin's NOTICE file """ htrace-core Copyright 2015 The Apache Software Foundation """ The good: * Can run with bin ta

Re: [VOTE] Accumulo 1.7.2-rc2

-1 (binding) HTrace's NOTICE is missing in -bin's NOTICE file """ htrace-core Copyright 2015 The Apache Software Foundation """ The good: * Can run with bin tarball out of the box. Simple write/read/update/read works in the shell. * `mvn verify -Psunny` passes on src tarball * xsums/sigs

Re: [VOTE] Accumulo 1.7.2-rc2

Dylan Hutchison wrote: +1 with notes below~ * NOTICE and LICENSE look good to my inexperienced eyes. * Source-compiled binary tar.gz matches the binary tar.gz artifact, except for META-INF entries. * Unit tests pass. * Good checksums and sigs. Fingerprint matches Mike's key. * Graphulo tests

Re: Code Quality Improvements for accumulo

Hi George, We would be happy for any contributions you'd like to make to Accumulo. We do try to keep up on what Findbugs reports already but I'm sure some slip through. I've cc'ed the developer list. Please use that for future correspondence. Thanks! - Josh On Jun 19, 2016 12:51 PM, "George

Re: [VOTE] Accumulo 1.7.2-rc1

Mike Drob wrote: Thanks for taking a look, Sean. The LICENSE file in the source tarball refers to the BSD license and includes "for details see core/src/main/java/org/apache/accumulo/core/bloomfilter" and all files there (BloomFilter.java, DynamicBloomFilter.java, and Filter.java) include the

Re: [VOTE] Accumulo 1.7.2-rc1

Thanks for the info, Mike! Keith Turner wrote: On Tue, Jun 14, 2016 at 5:47 PM, Mike Drob wrote: > Unit tests pass. > > ITs mostly pass. Have had transient failures on some, but have seen them > all pass as well: > DurabilityIT (ACCUMULO-4343) > ChaoticBalancerIT

Re: [VOTE] Accumulo 1.7.2-rc1

Thanks for putting this together, Mike. What kind of testing have you done so far and how have the results looked? Mike Drob wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.7.2. All content generated via assemble/build.sh --create-release-candidate -P

Re: Apache Accumulo integrated with Presto

. Using this approach, the query times were nearly identical whether the workers were co-located with tablet servers or not. On Mon, Jun 13, 2016 at 11:55 AM, Josh Elser<josh.el...@gmail.com> wrote: Adam J. Shook wrote: A few clarifications: - Presto supports hash-based distributed joins a

Re: Apache Accumulo integrated with Presto

Adam J. Shook wrote: A few clarifications: - Presto supports hash-based distributed joins as well as broadcast joins - Presto metadata is stored in ZooKeeper, but metadata storage is pluggable and could be stored in Accumulo instead - The connector does use tablet locality when scanning

Re: Minimum supported Hadoop?

For that reasoning, wouldn't bumping to 2.6.4 be better (as long as Hadoop didn't do anything screwy that they shouldn't have in a maintenance release...) I have not looked at deltas between 2.6.1 and 2.6.4 Christopher wrote: I was looking at the recently bumped tickets and noticed

No more Jenkins ITs from me

I had a talk with Christopher today in IRC which ultimately boiled down to him asking me to disable the Jenkins emails which I run which are sent to notifications@a.a.o. For a long time now, my little server which can usually run 1.6 ITs has been unable to run the full IT suite on >=1.7 (read

Re: Discussion: Address binding for monitor.

Ed Coleman wrote: Discovered the way the monitor determines the hostname and publishes address for the monitor log forwarding, that is written to zookeeper for clients, changed slightly between 1.6.4 and 1.6.5. Being (one of?) the people who has been messing with this recently, this seems

Re: Fwd: Accumulo-Test-1.6-Hadoop-1 - Build # 1032 - Failure!

, but not in the old ones. On Fri, May 27, 2016 at 11:58 AM Josh Elser<josh.el...@gmail.com> wrote: Thanks :) Christopher wrote: Oh, crap, I messed up jar sealing (didn't notice because we normally skip tests during a release, and we previously only sealed jars during a release). I will fix that later

Re: Fwd: Accumulo-Test-1.6-Hadoop-1 - Build # 1032 - Failure!

Hmm. I tested all of them. The PIAB builds were already failing... but I'll look at it later today. On Fri, May 27, 2016 at 2:13 AM Josh Elser<josh.el...@gmail.com> wrote: Correction, all of 1.6 and 1.7 appear busted after Christopher's asf pom version update. On May 26, 2016 11:11 PM,

Re: Fwd: Accumulo-Test-1.6-Hadoop-1 - Build # 1032 - Failure!

Correction, all of 1.6 and 1.7 appear busted after Christopher's asf pom version update. On May 26, 2016 11:11 PM, "Josh Elser" <josh.el...@gmail.com> wrote: > Looks like hadoop-1 is still having problems on 1.6. > -- Forwarded message -- > From: <els..

Fwd: Accumulo-Test-1.6-Hadoop-1 - Build # 1032 - Failure!

Looks like hadoop-1 is still having problems on 1.6. -- Forwarded message -- From: Date: May 26, 2016 8:40 PM Subject: Accumulo-Test-1.6-Hadoop-1 - Build # 1032 - Failure! To: Cc: Accumulo-Test-1.6-Hadoop-1 - Build # 1032 - Failure:

Re: [DISCUSS] Time for a 1.8.0 release?

Looks great to me. You now have the power to decide if RCs for 1.8.0 are zero or one indexed. Choose wisely ;) On May 26, 2016 5:57 PM, "Michael Wall" wrote: > Didn't get a chance to talk to Christopher so hopefully what I understood > from emails with Josh and him is correct.

Re: [DISCUSS] Release 1.7.2

Yay! That would be awesome, Mike! I'll go through the 1.7.2 ones I see right now and tag any that I think need special attention. Mike Drob wrote: Following up on the 1.8.0 release thread, maybe we should also get a 1.7.2 release going as well. I'll probably go through and move issues out to

Re: [DISCUSS] Time for a 1.8.0 release?

I'll try to take a look at this one tonight to have another set of eyes on it. Keith Turner wrote: I just opened a PR for ACCUMULO-1124, thats one change I wanted to get in for 1.8. The other change I would like to get in is ACCUMULO-4165. I will try my best to get a PR for that in tomorrow.

Re: [DISCUSS] Time for a 1.8.0 release?

You can always feel free to move them all out to a 1.9 and people who care about certain ones can move them back into the release and make them blockers. Less work for you :) Thanks for volunteering to be RM! On May 22, 2016 9:42 PM, "Michael Wall" wrote: > After last weeks

Fwd: Accumulo-Test-1.6-Hadoop-1 - Build # 1029 - Unstable!

Looks like the 2.1 upgrade failed on 1.6 with Hadoop-1. Did you happen to notice this, Dave? Original Message Subject: Accumulo-Test-1.6-Hadoop-1 - Build # 1029 - Unstable! Date: Fri, 20 May 2016 17:29:15 + (UTC) From: els...@apache.org To: josh.el...@gmail.com

[ANNOUNCE] Apache Commons VFS 2.1 released

The Apache Commons team is pleased to announce the release of Apache Commons VFS 2.1. Apache Commons VFS provides a single API for accessing various different file systems. It presents a uniform view of the files from various different sources, such as the files on local disk, on an HTTP

Co-working group on May 17th

I forgot to mention earlier that a small number of us got together on the 17th to work in proximity to each other. Myself, Billie, Keith, Mike Wall, Mike Walch, and Christopher were present at points throughout the day (The common prefix on the "Mike Wal*"'s is pretty great, IMO). There

Re: Accumulo folks at Hadoop Summit San Jose

Try to make the meetup that Billie is setting up and be sure to introduce yourself :) I'll be there this year (if that wasn't obvious by me asking) Claudia Rose wrote: I'll be there although I don't know the other "folks" yet. -Original Message----- From: Josh Elser [mail

Accumulo folks at Hadoop Summit San Jose

Out of curiosity, are there going to be any Accumulo-folks at Hadoop Summit in San Jose, CA at the end of June? - Josh

Re: [RESULT] [VOTE] Apache Commons VFS 2.1 rc2

you a case of beer. - Original Message - From: "Josh Elser"<josh.el...@gmail.com> To: "dev"<dev@accumulo.apache.org> Sent: Wednesday, May 18, 2016 11:41:05 AM Subject: Fwd: [RESULT] [VOTE] Apache Commons VFS 2.1 rc2 Holy . We actually got it do

Fwd: [RESULT] [VOTE] Apache Commons VFS 2.1 rc2

Holy . We actually got it done :P Original Message Subject: [RESULT] [VOTE] Apache Commons VFS 2.1 rc2 Date: Wed, 18 May 2016 11:40:21 -0400 From: Josh Elser <els...@apache.org> To: Commons Developers List <d...@commons.apache.org> We've let this go a bit

Re: Accumulo not initializing

Adina Crainiceanu wrote: Amila, 2 ideas: 1) Are you sure that Zookeeper started successfully? Maybe it did not. Make sure the permissions on that local dir you used for dirData are correct. Try the sudo echo ruok | nc 127.0.0.1 2181 if you don;t get imok back, start Zookeeper Thread

Re: Pros and Cons of moving SKVI to public API

Oy, that really did not come across well for me in email-form. Can you use paste.a.o or something? +1 for moving "internal-only" iterators and IteratorUtils. Neither are things that we intend for users to need. IMO, IteratorEnvironment was also kind of hokey/goofy (I never really used it

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

has a fail/no-fail mode, but it doesn't allow custom exceptions like findbugs. It's more like checkstyle in that way. It's either on or off. On Fri, May 6, 2016 at 12:11 PM Josh Elser<josh.el...@gmail.com> wrote: +1 to that, too Dave Marion wrote: It's 2.0, remove mock and deprecate it

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

JDK8 *requires* a bump in the major version, because modernizer > will block on some incompatible API changes in Mock, which is already > deprecated. (Unless we're okay with disabling modernizer... which I guess > is an acceptable solution... but it makes me unhappy :) ) > > On Thu, May 5,

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

Thanks boss. I figured you'd have my back :) On May 5, 2016 9:43 PM, "Christopher" <ctubb...@apache.org> wrote: > Already pushed. Initially forgot about modernizer, but I'm working through > it now. > > On Thu, May 5, 2016 at 7:25 PM Josh Elser <josh.el...@gmai

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

to stop development on 1.x stuffs, or says anything about when we'll release a 2.0, but it'd be nice to have a place to start putting in stuff for an eventual 2.0. On Thu, May 5, 2016 at 11:07 AM Josh Elser<josh.el...@gmail.com> wrote: Ok, looks to me that we are in agreement now and don'

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

6 at 4:33 PM Josh Elser<josh.el...@gmail.com> wrote: Gotcha. Thanks for clarifying, Mike -- I'm inclined to agree with you. I can't think of a reason why we would upgrade to Java8 and not make use of it in some way (publicly or privately). That being said, I don't think I see consensus.

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

ompilation (linking?) errors, regardless of java 8 types in our methods signatures. On Tue, May 3, 2016 at 3:09 PM, Josh Elser<josh.el...@gmail.com> wrote: That's a new assertion ("we can't actually use Java 8 features util Accumulo-2"), isn't it? We could use new Java 8 featu

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

ution. Another idea is we could potentially have some guarantee for Java 7, such as making sure we can build a distribution using Java 7, but only distribute Java 8 artifacts by default? On Mon, May 2, 2016 at 2:30 PM, Josh Elser<josh.el...@gmail.com> wrote: Sean Busbey wrote: O

Re: using Range.prefix

Suggestions (preferably in patch form ;D) about how to improve the documentation's clarity are always appreciated. z11373 wrote: Ah.. I think I've gone thru the same issue some time back, and I forgot. The documentation is somewhat not obvious, at least for me. Anyway, it's working now. Thanks

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

Sean Busbey wrote: On Mon, May 2, 2016 at 8:55 AM, Josh Elser<josh.el...@gmail.com> wrote: > Thanks for the input, Sean. > > Playing devil's advocate: we didn't have a major version bump when we > dropped JDK6 support (in Accumulo-1.7.0). Oracle has EOL'ed java 7 back

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

16 at 10:31 AM, Mike Drob<md...@apache.org> wrote: Wasn't 1.7.0 pre SemVer? On Mon, May 2, 2016 at 8:55 AM, Josh Elser<josh.el...@gmail.com> wrote: Thanks for the input, Sean. Playing devil's advocate: we didn't have a major version bump when we dropped JDK6 support (in Accumulo-

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

com> To: "dev@accumulo apache. org"<dev@accumulo.apache.org> Sent: Monday, May 2, 2016 1:54:53 AM Subject: Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache) If we drop jdk7 support, I would strongly prefer a major version bump. On S

Re: [DISCUSS] Java 8 support (was Fwd: [jira] [Commented] (ACCUMULO-4177) TinyLFU-based BlockCache)

would strongly prefer a major version bump. On Sun, May 1, 2016 at 1:43 PM, Josh Elser<josh.el...@gmail.com> wrote: Folks -- Let's come up with a plan for Java 8 support. Do we bump minJdk for accumulo-1.8.0 to 8? Should we fork a branch for 1.8 and make master 2.0.0-SNAPSHOT (and

Re: On the future of our commons-vfs2 dynamic classloading implementation

). As such, I volunteered to be an RM for 2.1. I'm waiting on an ACK from them, but I don't anticipate any negative feedback. dlmar...@comcast.net wrote: Josh, I see that you have made progress. Let me know how I can help get this released. Dave - Original Message - From: "Josh

Re: Fwd: Data authorization/visibility limit in Accumulo

Yeah, for building a real security-tagging system, the labeling that Accumulo does is only one "piece of the puzzle". For example, you would likely have external systems that define the authorizations that your users would have. The authorization and labeling that Accumulo does is a hard piece

Re: Accumulo on s3

Shawn -- you win the gold star for the day from me. This is exactly the fear I had, but had an inability put it into words correctly :) Valerio/chutium -- The common scenario I have run into is that processing jobs (your use of Spark) can read data from S3 and ingest it into the database

Fwd: [VFS] 2.1 Release Plan

FYI -- if anyone would like to follow on, see dev@c.a.o Original Message Subject: [VFS] 2.1 Release Plan Date: Mon, 25 Apr 2016 15:06:03 -0400 From: Josh Elser <els...@apache.org> To: d...@commons.apache.org Hi all, There are presently 171 resolved issues sitting in c

Re: On the future of our commons-vfs2 dynamic classloading implementation

in that community as I have been outspoken on the lack of movement. It might be useful for someone else to try once more, and if not, then we fork VFS, remove all of the things we don't need, and make it better. - Original Message - From: "Josh Elser"<josh.el...@gmail

Re: Accumulo on s3

are friendly to run on? I thought I remembered you and others running the agitation tests on Amazon instances during release-testing time. If there are alternatives, what advantages would S3 have over the current method? On Mon, Apr 25, 2016 at 8:09 AM, Josh Elser<josh.el...@gmail.com> wrote:

Re: On the future of our commons-vfs2 dynamic classloading implementation

on, Apr 25, 2016 at 10:35 AM, Josh Elser<josh.el...@gmail.com> wrote: I was trying to test out Dylan's patch this weekend and was met with a repeated failure of another VFS unit test due to the same race condition we've been fighting against for years. A cursory glance to vfs' we

On the future of our commons-vfs2 dynamic classloading implementation

I was trying to test out Dylan's patch this weekend and was met with a repeated failure of another VFS unit test due to the same race condition we've been fighting against for years. A cursory glance to vfs' website show still shows that they haven't made the 2.1 release which supposedly

Re: Accumulo on s3

I'm not sure on the guarantees of s3 (much less the s3 or s3a Hadoop FileSystem implementations), but, historically, the common issue is lacking/incorrect implementations of sync(). For durability (read-as: not losing your data), Accumulo *must* know that when it calls sync() on a file, the

Regarding JIRA spam

I wanted to take a moment to personally say "thank you" to everyone who has been helping out with the recent deluge of bogus JIRA issues. It's very much appreciated. ICYMI, there's some ongoing chatter on infrastructure@a.o regarding correction that INFRA is pursuing to negate this further

Re: Checking what a BatchWriter is stuck on; failure during split

l2qz53bbdruvo0pira...@mail.gmail.com%3E On Tue, Apr 19, 2016 at 6:26 PM, Josh Elser<josh.el...@gmail.com> wrote: Nice findings. Sorry I haven't had any cycles to dig into this myself. I look forward to hearing what you find :) Dylan Hutchison wrote: I investigated a bit more and I am

Re: Checking what a BatchWriter is stuck on; failure during split

Nice findings. Sorry I haven't had any cycles to dig into this myself. I look forward to hearing what you find :) Dylan Hutchison wrote: I investigated a bit more and I am pretty sure the problem is that the BatchWriter is not recognizing that the tablet vb<< split into vb;2436< and

Re: Our API compatibility history

Awesome. This is pretty cool. Thanks for sharing :) Sean Busbey wrote: yeah, it was pretty rough the first go around. at first I was like "oh jeez what have I done." :) On Fri, Apr 15, 2016 at 10:38 PM, Christopher wrote: That's cool. Thanks for having him update it

Re: Fwd: Data authorization/visibility limit in Accumulo

Hi Fikri, Welcome! You're the first Accumulo enthusiast I've heard from in Indonesia :) Responses inline: Fikri Akbar wrote: Hi Guys, We're a group of accumulo enthusiasts from Indonesia. We've been trying to implement accumulo for several different type of data processing purposes. We've

Re: Master Thesis on False Positives in Test Failures

Hi Kevin, Many of those test bugs and fixes were probably my doing. Most of them were just flakiness in general, but, if you can provide an explicit list, I can try to confirm whether or not that was exactly the case. - Josh Kevin van den Bekerom wrote: Dear Developers of the Apache

Re: LruBlockCache alternative

Cool, thanks for the poke, Ben! Last I checked, our version of the LRUBlockCache was nearly identical to what was in HBase 1.x. I would imagine this would be easy to bring over. Maybe we can also try to swipe BucketCache while we're at it and get some off-heap support for blocks. Aside: it

Re: Anyone else have trouble running all integration tests on a Mac?

There is a -Dtimeout.factor option you can set on the Maven CLI to scale up the timeouts. e.g. `mvn verify -Dtimeout.factor=2` would double the default test timeouts. Interesting that both of the failures are from stopping processes, but that might be circumstantial? Dunno for sure.

Re: 1.6 Javadoc missing classes

So this just bit me. I went looking for Iterators and was confused why they weren't there. Christopher wrote: Sure, we can include that. Are there any other classes which would be good to have javadocs for which aren't public API? On Fri, Mar 4, 2016 at 4:03 PM Josh Elser <josh

Re: Pros and Cons of moving SKVI to public API

That was my gut reaction too. Separating "public API" by artifact would be my preferred way to tackle it moving forward. Until then, trying to maintain our current approach seems reasonable to me. If there's some reason with how we have things structured now which makes this

Re: Pros and Cons of moving SKVI to public API

Billie Rinaldi wrote: On Thu, Mar 24, 2016 at 1:15 PM, Christopher wrote: > We do have the opportunity to move to a new improved API, if somebody were > to put time into it. I guess that's true whether we put this in the public > API officially or not. Agreed. Even

Re: delete + insert case

Server-assigned timestamps aren't noticeably slower than user-assigned timestamps, if that's what you're referring to WRT throughput. As for using currentTimeMillis(), probably fine, but not always. 1) NTP updates might cause currentTimeMillis() to change in reverse 2) You need to make sure

Re: git-based site and jekyll

One thing I just noticed is that the quick "anchor" links at the end of each header (specifically on the release notes page) are missing. I liked those because it was easy to click the header to get a url and use it to reference. The IDs are still there on each section, just the quick link

Re: delete + insert case

Server-assigned timestamps are done per-batch. This is getting back to what Keith suggested. It's not that Accumulo isn't "setting the timestamp properly" like you suggest, this is just how server-assigned time works. If you submit a delete and an update, without timestamps, in the same

Re: delete + insert case

Make sure that your insert has a newer timestamp than the delete does. Otherwise, the delete will mask any inserts with smaller timestamps until it is compacted away (which is essentially an unknown to you as a client). e.g. 1. delete A ts=5 2. add A ts=6 3. add B ts=whatever z11373 wrote:

Re: git-based site and jekyll

s you saw were existing bugs with either our HTML or our Markdown... but whatever CMS is doing is a bit more tolerant than Kramdown is apparently. Biggest problem I saw was that people keep forgetting quotes around HTML attributes. Example, it should be, not. On Thu, Mar 10, 2016 at 9:57 PM Josh Elser&

Re: git-based site and jekyll

t http://ctubbsii.github.io/accumulo) Yes, it's terrible right now... it's in progress. :) On Tue, Mar 8, 2016 at 4:21 PM Josh Elser<josh.el...@gmail.com> wrote: Lazy consensus is fine. If there are no objections, I don't want to hold things up. I feel like I've adequately expressed my conce

Re: git-based site and jekyll

proceed. On Tue, Mar 8, 2016 at 3:22 PM Josh Elser<josh.el...@gmail.com> wrote: Well, I think the difference is that archive.org (and others -- google cached pages come to mind) are devoted/known for that specific purpose. The fact that Github ends up being a "de-facto" location for s

Re: git-based site and jekyll

simple enough to do. On Tue, Mar 8, 2016 at 1:36 PM Josh Elser<josh.el...@gmail.com> wrote: It's also probably worth mentioning that this concern only comes about for point #4 (or if we use the branch name gh-pages in point #1). Josh Elser wrote: The one concern I had was regarding automatic re

Re: git-based site and jekyll

It's also probably worth mentioning that this concern only comes about for point #4 (or if we use the branch name gh-pages in point #1). Josh Elser wrote: The one concern I had was regarding automatic rendering of what would look like "the Apache Accumulo website" on Github (b

Re: Broken website links (talks)

. Josh Elser wrote: ./content/papers.mdtext: http://people.apache.org/~kturner/accumulo14_15.pdf;>slides ./content/papers.mdtext: http://people.apache.org/~afuchs/slides/morgan_state_talk.pdf;>slides Keith/Adam -- any chance you can relocate your referenced talks off of people.a.o (which was re

Broken website links (talks)

./content/papers.mdtext: href="http://people.apache.org/~kturner/accumulo14_15.pdf;>slides ./content/papers.mdtext: href="http://people.apache.org/~afuchs/slides/morgan_state_talk.pdf;>slides Keith/Adam -- any chance you can relocate your referenced talks off of people.a.o (which was

Re: 1.6 Javadoc missing classes

wrote: The tracing APIs vary from version to version significantly. That puts a lot of extra effort on the person updating the included packages. How important are those now we're transitioning to use an external dependency? On Fri, Mar 4, 2016 at 5:17 PM Josh Elser <josh.el...@gmail.

Re: 1.6 Javadoc missing classes

Maybe the distributed tracing APIs? Christopher wrote: Sure, we can include that. Are there any other classes which would be good to have javadocs for which aren't public API? On Fri, Mar 4, 2016 at 4:03 PM Josh Elser <josh.el...@gmail.com <mailto:josh.el...@gmail.com>> wrote:

Re: [ATTN] Cleaning up extra refs in git

Thanks for taking the time to clean these up! Christopher wrote: Not much change. After doing 'git gc --aggressive --prune=now' on a 'git clone --mirror', the repo size was 33M before the removal of these refs, and 27M after. Since they were mostly pointing to existing blobs, I wouldn't expect

Fwd: 1.6 Javadoc missing classes

Good catch, Dan. Thanks for letting us know. Moving this one over to the dev list to discuss further. Christopher, looks like it might also be good to include iterator javadocs despite not being in public API (interfaces, and o.a.a.c.i.user?). Original Message Subject: 1.6

Re: Notes from a local co-working day

certain that I could organize some space fairly nearby for a similar event. -Russ On Thu, Mar 3, 2016 at 4:07 PM Josh Elser<josh.el...@gmail.com> wrote: Hi all, A group of us in central MD met today at a local business (which was gracious enough to donate a conference room today) and enjo

Notes from a local co-working day

Hi all, A group of us in central MD met today at a local business (which was gracious enough to donate a conference room today) and enjoy each others' presence while hacking on some code. In the spirit of no private discussions, I made sure to keep a record of the relevant Accumulo talking

Unsubscribing from mailing lists (Re: [GitHub] accumulo pull request: ACCUMULO-4152 add fate dump command)

Chris, Just as you subscribed yourself in the first place, you must also unsubscribe yourself. dev-unsubscr...@accumulo.apache.org Chris Rigano wrote: Please remove me from the list.

Re: cached connector

None of the create* methods should be too bad. They aren't going to do much until you use them (e.g. Scanner, BatchScanner, BatchWriter). getUserAuthorizations is going to be an Accumulo RPC and a (cached) ZooKeeper lookup in the server. This won't be bad unless you're calling it in a really

Re: cached connector

I guess it's also worth saying that while Connectors can be cached, it's not "necessary" like it is for other database connectors. The Accumulo Connector is very light-weight and cheap to construct. Josh Elser wrote: z11373 wrote: My questions: 1. Since I haven't killed that servic

[RESULT] [VOTE] Accumulo 1.7.1-rc2

s, apologies if I gave that impression. I'm sure we'll figure this out, and if it is a problem in Accumulo's Kerberos feature (and not something stupid on my end), I'm sure we're committed to fixing it quickly and having it in the next bugfix release. On Thu, Feb 25, 2016 at 12:31 PM Josh E

Re: [VOTE] Accumulo 1.7.1-rc2

Josh Elser<josh.el...@gmail.com> wrote: Welcome to why people say "Kerberos is hard". I think I said in chat, but increasing the timeout factor is not going to make that test pass if it can't pass the first time. The MiniKDC the tests use are not representative of a real KDC.

Re: [VOTE] Accumulo 1.7.1-rc2

Welcome to why people say "Kerberos is hard". I think I said in chat, but increasing the timeout factor is not going to make that test pass if it can't pass the first time. The MiniKDC the tests use are not representative of a real KDC. I'd ask that you deploy Accumulo with Kerberos before

Re: Review Request 43957: ACCUMULO-1755: removed synchronized modifier from TabletServerBatchWriterstartProcessing()

> On Feb. 24, 2016, 7:15 p.m., Josh Elser wrote: > > core/src/main/java/org/apache/accumulo/core/client/impl/TabletServerBatchWriter.java, > > line 974 > > <https://reviews.apache.org/r/43957/diff/1/?file=1268376#file1268376line974> > > > > Don

Re: [VOTE] Accumulo 1.7.1-rc2

+1 * Checked sigs/xsums * Ran japi checks against 1.7.0 * `mvn verify -Psunny` (had a couple of transient failures) Christopher wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.7.1. Git Commit: 2e0821ad88c03fa643d4924ed13622834d5770f1 Branch:

Re: [VOTE] Accumulo 1.7.1-rc2

dn't occur while preparing the RC, and I haven't seen it since. What JDK were you using? I wonder if that could've made a difference. On Mon, Feb 22, 2016 at 8:30 PM Josh Elser<josh.el...@gmail.com> wrote: I got a findbugs failure on rc2: http://paste.apache.org/glEb Is it me, or

Re: [VOTE] Accumulo 1.7.1-rc2

I got a findbugs failure on rc2: http://paste.apache.org/glEb Is it me, or have others seen this? Christopher wrote: 1.7.1-rc2 includes everything from 1.7.1-rc1, plus: https://issues.apache.org/jira/browse/ACCUMULO-4138 https://issues.apache.org/jira/browse/ACCUMULO-4141 On Mon, Feb 22,

Re: [DISCUSS] Pulling out the examples

of them already) which outlines the concerns and states how they will be mitigated. This would make it very clear if/when we move from DISCUSS->VOTE. Christopher wrote: On Thu, Feb 18, 2016 at 7:37 PM Josh Elser<josh.el...@gmail.com> wrote: I'd like to see some process put i

Re: [DISCUSS] Pulling out the examples

Christopher wrote: I also wonder what the ASF rule-of-thumb is for stuff like this... the examples aren't really "projects" in the sense that they are moving towards an official ASF "release", so much as they are code serving as runnable documentation. I do have the concern that every

Re: [DISCUSS] Pulling out the examples

I'd like to see some process put into place to mitigate "bit-rot". If the examples don't live in the "main" repository, how do we make sure they don't get ignored and become dead or "bad" code? For questions at the foreground now: * Can we set up new CI jobs that build the new examples repo

Re: [DRAFT] [ANNOUNCE] Apache Accumulo 1.6.5

LGTM, made two slight tweaks to the release notes (basic grammar/english). Christopher wrote: The Apache Accumulo project is pleased to announce its 1.6.5 release. Version 1.6.5 is the most recent bug-fix release in its 1.6.x release line. This version includes several bug fixes since 1.6.4.

Re: On 1.7.1 rc1 (was Re: [VOTE] Accumulo 1.6.5-rc2)

Josh Elser wrote: Christopher wrote: I'll wrap up this releasetomorrow and get started on 1.7.1 soon. FYI, I want to ping William about ACCUMULO-4140. His wording is a little scary. I'd like to find some time today to look into it. Just pushed this. I was seeing some intermittent failures

Re: On 1.7.1 rc1 (was Re: [VOTE] Accumulo 1.6.5-rc2)

Yes, Wilhelm. William Slacum wrote: "William" is my grandfather. Please refer to me as "Sir William". On Wed, Feb 17, 2016 at 8:44 AM, Josh Elser<josh.el...@gmail.com> wrote: Christopher wrote: I'll wrap up this releasetomorrow and get started on 1.7.1 s

On 1.7.1 rc1 (was Re: [VOTE] Accumulo 1.6.5-rc2)

Christopher wrote: I'll wrap up this releasetomorrow and get started on 1.7.1 soon. FYI, I want to ping William about ACCUMULO-4140. His wording is a little scary. I'd like to find some time today to look into it.

Re: Fwd: Accumulo-Integration-Tests - Build # 663 - Still Failing! -- 1.7

Ya, I know I need to update it. Thanks for the ping, though. Christopher wrote: Hey elserj, There's a lot of builds failing on your Jenkins because it's running an outdated (unsupported) version of Maven (3.0.4), but I don't have permission to change the version, install additional versions,

Re: [VOTE] Accumulo 1.6.5-rc2

+1 Thanks for the quick turnaround on this one. Verified the reasons for my discomfort on rc1 have been resolved. Christopher wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.6.5. Git Commit: c8ad82dbcd0994a37956a2be407de56ad26a562f Branch:

Re: [VOTE] Accumulo 1.6.5-rc1

-0 * Copyright year is wrong in NOTICE -- ACCUMULO-4142 * src L look ok (sans 4142) * bin L look ok (sans 4142) * Built src, ran all tests (ran into ACCUMULO-4139, ACCUMULO-4143 and a intermittent failure on ConditionalWriterIT#testTrace which I've seen before). * Checked fwd/rev bin/src

Re: [VOTE] Accumulo 1.6.5-rc1

Anyone run the jdiff yet against 1.6.4? Christopher wrote: Accumulo Developers, Please consider the following candidate for Accumulo 1.6.5. Git Commit: 2263fabd57e765ab14fc47a146b1e2d443e705ca Branch: 1.6.5-rc1 If this vote passes, a gpg-signed tag will be created using: git

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