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 implementation
Hi,
When running stress test, we saw a lot of requests coming to one particular
tserver, and since the row id range (for the scan) is generated in random
manner, then ideally the requests should go to all 3 tservers since the data
in the tablets also should be distributed nicely.
I recall that I e
Github user ctubbsii commented on the pull request:
https://github.com/apache/accumulo/pull/63#issuecomment-170110128
If you put the move and the rename in separate commits, it might be easier
to examine in the GitHub interface... not sure it's worth it, though.
---
If your project i
Github user joshelser commented on the pull request:
https://github.com/apache/accumulo/pull/63#issuecomment-170102128
> I wish I could see the files side-by-side in GitHub to review, but the
file was moved in addition to being updated, so GitHub is confused. :(
Blarg. The cru
Github user ctubbsii commented on the pull request:
https://github.com/apache/accumulo/pull/63#issuecomment-170101045
I wish I could see the files side-by-side in GitHub to review, but the file
was moved in addition to being updated, so GitHub is confused. :(
We used to have a
Thanks all for the quick responses!
I'm not sure what all integration there is with GH directly. I know
Yetus is smart enough to find PR's when they end in .patch when
commented on a JIRA issue (e.g.
https://github.com/apache/accumulo/pull/63.patch).
I would guess that attachments are only l
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.
Please drop me from this list.
On Fri, Jan 8, 2016 at 12:58 PM, Keith Turner wrote:
> +1
>
> On Fri, Jan 8, 2016 at 12:24 PM, Josh Elser wrote:
>
> > Hi,
> >
> > Per the other thread "Yetus Accumulo 'Personality'" [1], I'd like to see
> > what people think about turning this on by default.
> >
On by default: +1
Separate JIRA account: makes sense
Concerns about -1/+1 in CTR: it's informs the committers, but isn't
binding, so I'm not concerned
Questions:
Is this just for PRs or patches, too? If patches also, how do we identify
patches vs. other JIRA attachments?
How do other committers/PM
+1
On Fri, Jan 8, 2016 at 12:58 PM Keith Turner wrote:
> +1
>
> On Fri, Jan 8, 2016 at 12:24 PM, Josh Elser 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
+1
On Fri, Jan 8, 2016 at 12:24 PM, Josh Elser 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 own JIRA acct ins
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
12 matches
Mail list logo
