Re: Storing Geospatial Tiles in Accumulo Question

If you google storing hilbert curves, you'll find a few links, which I used in college to help store this data. it will also prove useful for you, as you can probably structure and normalize to store them as keys On Tue, Jun 26, 2012 at 9:31 AM, Thistlethwaite, Susan - IS

Re: c++ thrift client crash

I ran into this a lot when performing operations like bulk load, writing, and scanning accumulo from c++. I wasn't using the proxy, but I ran into this a lot 1) My first likely cause was issues of endianness. I assume the proxy takes care of thisso perhaps this is moot. 2) The next most likely

Re: c++ thrift client crash

I'm sorry, I'm not terribly familiar to the proxy as I was making the RPC calls in my client. I did not come across that exception. Do you know if that is your local client or an exception generated in the proxy and returned to you? On Tue, Apr 26, 2016 at 11:30 AM z11373

Re: [VOTE] Accumulo 1.8.0-rc1

Did you provide an instance name when prompted or simply hit enter? On Sat, Aug 13, 2016 at 4:53 PM, Josh Elser wrote: > I downloaded the binary tarball and tried to set this up, but I cannot get > `accumulo init` to run. It just keeps prompting me for the instance name >

Re: Snappy as default table.file.compress.type?

Perhaps there is a happy medium, though, by not necessarily defining example configurations by the size of your memory footprint, but instead by performance configuration? Snappy could be the default for those who want a faster but less space cognizant implementation. Christopher's concerns would

Re: Snappy as default table.file.compress.type?

In many cases , I would imagine faster is better . On Sat, Aug 13, 2016, 10:56 PM Christopher wrote: > What's the motivation for changing it? > > On Sat, Aug 13, 2016 at 10:47 PM Josh Elser wrote: > > > Any reason we don't want to do this? Last

Re: [VOTE] 1.8.1-rc1

+1 On Tue, Feb 21, 2017, 2:44 PM Mike Miller wrote: > +1 New signatures check out. Release notes look good too. Only thing I > noticed is use of the word "fate" for our FATE acronym but that seems to > just be taken from its use in the tickets. > > On Tue, Feb 21,

Re: exception from thrift

Could be a number of causes. If you are not using the proxy I'd ensure the tserver is still hosting after a split. If you are you can get more info from the exception. In my CPP client I take failed mutations and requeue them depending on the exception details. If the extent locations have

Re: exception from thrift

Z, Is this your custom thrift RPC call or an object against the thrift proxy? If you are connecting to the proxy, then perhaps explore the exception further there or within Accumulo's Monitor. Depending on the problem that's occurring a retry will likely yield the same result. Do you have access

Re: BatchWriter Auth/Audit Question

Sorryby out of band, It could be done once per writer or even in the connector once...but I think we're in agreement Drob, Mike. On Fri, Aug 19, 2016 at 2:30 PM, Marc P. <marc.par...@gmail.com> wrote: > Funny, exactly the same thing I mentioned to Josh last night. Are you >

Re: BatchWriter Auth/Audit Question

Funny, exactly the same thing I mentioned to Josh last night. Are you watching us? In something I"m doing now I'm making the thrift calls and modeled it after what the client code does; however, once I removed the authenticateUser my throughput increased by 25 per cent. In my trace table it was

Re: [VOTE] Accumulo 1.8.0-rc3

Checksums matched, built and verified source/bin. Looks good to me. I've been running integration tests most of the morning. A handful of failures which I was able to resolve by re-running, so I don't think it's code related. FWIW I ran four hours of RPC testing using the Thrift calls,

Re: Lots of "Connection reset by peer"

Yah I saw this a lot when I wasn't closing thrift connections...but also saw it when the client would close prematurely and not return the transport to the thrift transport pool . In one case I hadn't finished with the work in a thread but kept opening thrift connections since it would be 'time

Re: [DISCUSS] How to bring more pluggable interfaces into public API

I tend to think that what can be configured now is tailored to the infrastructure engineers? With the exception of SKVI, is it short sighted to suggest that the consumers of said APIs are generally few and far between? Those flexible APIs exist for the John "Ain't no mountain high enough" Vines

Re: [VOTE] Plan for next release

I think there is value in commenting because after Reading the responses last night I was swayed to -1. Perhaps others might be as well. On Tue, Aug 23, 2016 at 8:56 AM, wrote: > Agreed - this thread should be left to votes only. Let it pass or fail. > > - Original

Re: [VOTE] Plan for next release

Busbey <bus...@cloudera.com> wrote: > On Tue, Aug 23, 2016 at 8:03 AM, Marc P. <marc.par...@gmail.com> wrote: > > I think there is value in commenting because after Reading the responses > > last night I was swayed to -1. Perhaps others might be as well. > > > &g

Re: [VOTE] Plan for next release

+1 to move to 2.0 unless you plan on naming the release after me. On Mon, Aug 22, 2016 at 5:24 PM, Christopher wrote: > My vote is +1, because I don't think we *need* an extra release line named > 1.8, when a 2.0 release from master will suffice, and in particular because >

Re: [DISCUSS] Would a visibility histogram on a table be harmful?

What prevents the owners of the system from doing this in their own table? Keeping track of that information is a use case of Accumulo. I think this may be an example of external code that the user must install. Placing the onus on the consumer mitigates concern that Mike "Mike" Drob and others

Re: [DISCUSS] Would a visibility histogram on a table be harmful?

Beyond adding a tool on the side. It doesn't fit in metadata as that requires aggregated reads vs table aggregates data. On Wed, Oct 12, 2016, 11:02 AM Marc P. <marc.par...@gmail.com> wrote: > How does it increase ease of use? > > On Wed, Oct 12, 2016, 10:34 AM ivan bella <i.

Re: [DISCUSS] Would a visibility histogram on a table be harmful?

ot;ease of use". Unfortunately, system designers rarely think > about the metadata they need from their system up front. That being said, > if the performance impact of this is significant then it needs to be made > optional or we leave it as is. > > > > On October 12,

Re: [DISCUSS] Would a visibility histogram on a table be harmful?

My point for discussing implementation outside of accumulo is because I think it does invalidate a core tenant On Wed, Oct 12, 2016, 12:26 PM Josh Elser wrote: > Again, can we please bring this discussion back from discussions of > implementations to security? > > Does the

Re: Accumulo Table Sacanning Taking Time!!!

Suresh, There are a lot of configuration points that can have an impact. For example, there is a configuration option that dictates how much data is returned each "iteration," called table.scan.max.memory [0]. Increasing this will cause more work to be done in each RPC call to get data.

Re: [DISCUSS] Pull Request Guidelines

Dave, I don't agree that stylistic changes are something to ignore. There may be cases where something is confusing to others and thus should be called out. This is difficult to blatantly avoid. I can't agree with number two either since a PR can be a form of requirements elicitation and such

Re: [DISCUSS] Pull Request Guidelines

Turner and Tubbs, You both piqued my interest and I agree. There's something important in what both said regarding the discussion and importance of a particular change. Style changes most likely aren't deal breakers unless it is terribly confusing, but I would leave that up to the reviewer and

Re: [DISCUSS] Question about 1.7 bugfix releases

". I just think that pointer should probably currently point at branch-1.7 and should only be updated when we can show that we've done enough due diligence that the majority of downstream folks can expect an upgrade that doesn't come with surprises." +1 On Tue, Jun 6, 2017 at 2:10 PM, Sean

Re: New Accumulo git repository

Out of curiosity, what is the benefit of having a new repo over a release target of accumulo-visibility ? I've used VisibilityEvaluator on non Accumulo projects, so I can see some perceived benefit, but in those projects I wanted to support a visibility expression or ColumnVisibility "as Accumulo

Re: New committer - Dan Roberts

Congrats! On Fri, Aug 11, 2023 at 5:19 PM Keith Turner wrote: > Welcome and congratulations Dan. > > On Wed, Aug 9, 2023 at 6:27 PM dev1 wrote: > > > The Project Management Committee (PMC) for Apache Accumulo has invited > Dan > > Roberts to become a committer / PMC member and we are pleased