Gotcha, Billie. I realize that I misinterpreted what you were saying
earlier :)
I think it would be good for us to annotate properties which are not
dynamically picked up instead of relying on "words". Hopefully it is
very few properties which are not dynamically updating by now (but I'm
not
Yes, we keep track of both pieces of information in Property and that is
recorded in the user manual.
On Wed, Oct 5, 2016 at 8:57 AM, Josh Elser wrote:
> IIRC, a property being mutable in ZooKeeper is disjoint from whether it
> will be dynamically reloaded.
>
> That is, a mutable ZK property doe
That is what I recall as well Josh. It is confusing for sure.
On Wed, Oct 5, 2016 at 11:57 AM, Josh Elser wrote:
> IIRC, a property being mutable in ZooKeeper is disjoint from whether it
> will be dynamically reloaded.
>
> That is, a mutable ZK property does not imply that it is always
> dynami
IIRC, a property being mutable in ZooKeeper is disjoint from whether it
will be dynamically reloaded.
That is, a mutable ZK property does not imply that it is always
dynamically picked up.
Billie Rinaldi wrote:
We already keep track of this in the Property class, whether a property
can be ch
We already keep track of this in the Property class, whether a property can
be changed in ZooKeeper and whether it requires a restart. Perhaps the
information has grown stale, though. The information is exposed in the user
manual:
http://accumulo.apache.org/1.8/accumulo_user_manual#_tserver_port_cl
At most, yes.
The properties which affect both would be the ones which start with
"general." or "instance.", with the latter being ones which must be the
same across the cluster in order for servers to participate in the same
cluster.
For all X, not in {general, instance}, properties starting wit
So just to clarify, changing a tserver.* option would at most only require
a restart of all the tservers, not a restart of the master?
On Tue, Oct 4, 2016 at 9:14 PM, Christopher wrote:
> Right now, I think you'd probably have to track down where that particular
> property is used in the code t
Right now, I think you'd probably have to track down where that particular
property is used in the code to determine its lifecycle. I think it's going
to take some work to wrangle these into discrete sets for documentation
purposes, in the shell or otherwise. Some properties are only used during
ce
That would be very helpful, but a note in the documentation would be fine
initially. Is there an easy way to determine this from the source code?
--
Jeff Kubina
410-988-4436
On Tue, Oct 4, 2016 at 8:59 PM, Christopher wrote:
> Some do, some don't. One thing we could add to the shell is a noti
Some do, some don't. One thing we could add to the shell is a notification
that a restart is necessary for a particular change. Possibly.
On Tue, Oct 4, 2016, 20:25 Dave wrote:
> I don't think so.
>
> On Oct 4, 2016 8:21 PM, Jeff Kubina wrote:
>
> Does changing the values of tserver configs in
I don't think so.
On Oct 4, 2016 8:21 PM, Jeff Kubina wrote:Does changing the values of tserver configs in the accumulo shell, like "config -s tserver.server.threads.minimum=256", require a restart of all the tservers to become effective?
Does changing the values of tserver configs in the accumulo shell, like
"config -s tserver.server.threads.minimum=256", require a restart of all
the tservers to become effective?
12 matches
Mail list logo
