You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@accumulo.apache.org by Ara Ebrahimi <ar...@argyledata.com> on 2015/01/09 01:07:05 UTC
TableOperations.setProperty() not setting property
Hi,
I’m trying to set a few properties for a table “programmatically” right after I create that table (using accumulo shell). I use TableOperations.setProperty(). But then when I use the config command from accumulo shell I don’t see anything reflected there. It still holds the old default/site values. If I pass invalid values it does fail, so seems like it actually receives the request and validates it. But it does’t seem to persist it. I’ve tried a few different properties and none seem to stick. Do I need to flush the config somehow?
I assume I can set these properties right after creating table only. I mean, what happens if I set a property like table.split.threshold after populating the table? There’s no command for setting these properties from accumulo shell other than the option to copy config from another table when executing create table.
Thanks,
Ara.
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Thank you in advance for your cooperation.
________________________________
Re: TableOperations.setProperty() not setting property
Posted by Billie Rinaldi <bi...@gmail.com>.
On Thu, Jan 8, 2015 at 4:07 PM, Ara Ebrahimi <ar...@argyledata.com>
wrote:
> Hi,
>
> I’m trying to set a few properties for a table “programmatically” right
> after I create that table (using accumulo shell). I use
> TableOperations.setProperty(). But then when I use the config command from
> accumulo shell I don’t see anything reflected there. It still holds the old
> default/site values. If I pass invalid values it does fail, so seems like
> it actually receives the request and validates it. But it does’t seem to
> persist it. I’ve tried a few different properties and none seem to stick.
> Do I need to flush the config somehow?
>
> I assume I can set these properties right after creating table only. I
> mean, what happens if I set a property like table.split.threshold after
> populating the table? There’s no command for setting these properties from
> accumulo shell other than the option to copy config from another table when
> executing create table.
>
You can change the properties over the life of the table. With
table.split.threshold, you might choose to lower the value temporarily to
get the table to split more, then raise the value when you want to keep the
splits fixed for a while. You can set properties through the shell using
the config command, e.g. config -t tablename -s property=value
>
> Thanks,
> Ara.
>
>
>
> ________________________________
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited. Thank you in
> advance for your cooperation.
>
> ________________________________
>
Re: TableOperations.setProperty() not setting property
Posted by Ara Ebrahimi <ar...@argyledata.com>.
Ok user error. Didn’t realize “config” shows the global config even when you’ve changed to a table, while “config -t” shows config for a specific table. I was expecting it to behave like gesplits :) Everything is fine.
Ara.
> On Jan 8, 2015, at 5:01 PM, Ara Ebrahimi <ar...@argyledata.com> wrote:
>
> It just doesn’t show even minutes later. On the other hand, InstanceOpertions.setProperty() works and is reflected almost immediately (shown as “system” when running config command in shell).
>
> Ara.
>
>> On Jan 8, 2015, at 4:46 PM, Josh Elser <jo...@gmail.com> wrote:
>>
>> 30-60s is *very* generous. A few seconds should be sufficient. Also,
>> this is only relevant if you have more than one tabletserver.
>>
>> Versions and/or actual shell commands that you can reproduce this doing?
>>
>> Mike Drob wrote:
>>> Ara,
>>>
>>> There is sometimes propogation delay in setting the properties, since
>>> they have to go through zookeeper and then out to the tablet servers.
>>>
>>> Try waiting 30 or 60 seconds before checking, and see if that changes
>>> things.
>>>
>>> Mike
>>>
>>> On Thu, Jan 8, 2015 at 6:07 PM, Ara Ebrahimi
>>> <ara.ebrahimi@argyledata.com <ma...@argyledata.com>> wrote:
>>>
>>> Hi,
>>>
>>> I’m trying to set a few properties for a table “programmatically”
>>> right after I create that table (using accumulo shell). I use
>>> TableOperations.setProperty(). But then when I use the config
>>> command from accumulo shell I don’t see anything reflected there. It
>>> still holds the old default/site values. If I pass invalid values it
>>> does fail, so seems like it actually receives the request and
>>> validates it. But it does’t seem to persist it. I’ve tried a few
>>> different properties and none seem to stick. Do I need to flush the
>>> config somehow?
>>>
>>> I assume I can set these properties right after creating table only.
>>> I mean, what happens if I set a property like table.split.threshold
>>> after populating the table? There’s no command for setting these
>>> properties from accumulo shell other than the option to copy config
>>> from another table when executing create table.
>>>
>>> Thanks,
>>> Ara.
>>>
>>>
>>>
>>> ________________________________
>>>
>>> This message is for the designated recipient only and may contain
>>> privileged, proprietary, or otherwise confidential information. If
>>> you have received it in error, please notify the sender immediately
>>> and delete the original. Any other use of the e-mail by you is
>>> prohibited. Thank you in advance for your cooperation.
>>>
>>> ________________________________
>>>
>>>
>>
>>
>>
>> ________________________________
>>
>> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Thank you in advance for your cooperation.
>>
>> ________________________________
>
>
>
>
> ________________________________
>
> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Thank you in advance for your cooperation.
>
> ________________________________
>
>
>
> ________________________________
>
> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Thank you in advance for your cooperation.
>
> ________________________________
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Thank you in advance for your cooperation.
________________________________
Re: TableOperations.setProperty() not setting property
Posted by Ara Ebrahimi <ar...@argyledata.com>.
It just doesn’t show even minutes later. On the other hand, InstanceOpertions.setProperty() works and is reflected almost immediately (shown as “system” when running config command in shell).
Ara.
> On Jan 8, 2015, at 4:46 PM, Josh Elser <jo...@gmail.com> wrote:
>
> 30-60s is *very* generous. A few seconds should be sufficient. Also,
> this is only relevant if you have more than one tabletserver.
>
> Versions and/or actual shell commands that you can reproduce this doing?
>
> Mike Drob wrote:
>> Ara,
>>
>> There is sometimes propogation delay in setting the properties, since
>> they have to go through zookeeper and then out to the tablet servers.
>>
>> Try waiting 30 or 60 seconds before checking, and see if that changes
>> things.
>>
>> Mike
>>
>> On Thu, Jan 8, 2015 at 6:07 PM, Ara Ebrahimi
>> <ara.ebrahimi@argyledata.com <ma...@argyledata.com>> wrote:
>>
>> Hi,
>>
>> I’m trying to set a few properties for a table “programmatically”
>> right after I create that table (using accumulo shell). I use
>> TableOperations.setProperty(). But then when I use the config
>> command from accumulo shell I don’t see anything reflected there. It
>> still holds the old default/site values. If I pass invalid values it
>> does fail, so seems like it actually receives the request and
>> validates it. But it does’t seem to persist it. I’ve tried a few
>> different properties and none seem to stick. Do I need to flush the
>> config somehow?
>>
>> I assume I can set these properties right after creating table only.
>> I mean, what happens if I set a property like table.split.threshold
>> after populating the table? There’s no command for setting these
>> properties from accumulo shell other than the option to copy config
>> from another table when executing create table.
>>
>> Thanks,
>> Ara.
>>
>>
>>
>> ________________________________
>>
>> This message is for the designated recipient only and may contain
>> privileged, proprietary, or otherwise confidential information. If
>> you have received it in error, please notify the sender immediately
>> and delete the original. Any other use of the e-mail by you is
>> prohibited. Thank you in advance for your cooperation.
>>
>> ________________________________
>>
>>
>
>
>
> ________________________________
>
> This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Thank you in advance for your cooperation.
>
> ________________________________
________________________________
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Thank you in advance for your cooperation.
________________________________
Re: TableOperations.setProperty() not setting property
Posted by Josh Elser <jo...@gmail.com>.
30-60s is *very* generous. A few seconds should be sufficient. Also,
this is only relevant if you have more than one tabletserver.
Versions and/or actual shell commands that you can reproduce this doing?
Mike Drob wrote:
> Ara,
>
> There is sometimes propogation delay in setting the properties, since
> they have to go through zookeeper and then out to the tablet servers.
>
> Try waiting 30 or 60 seconds before checking, and see if that changes
> things.
>
> Mike
>
> On Thu, Jan 8, 2015 at 6:07 PM, Ara Ebrahimi
> <ara.ebrahimi@argyledata.com <ma...@argyledata.com>> wrote:
>
> Hi,
>
> I’m trying to set a few properties for a table “programmatically”
> right after I create that table (using accumulo shell). I use
> TableOperations.setProperty(). But then when I use the config
> command from accumulo shell I don’t see anything reflected there. It
> still holds the old default/site values. If I pass invalid values it
> does fail, so seems like it actually receives the request and
> validates it. But it does’t seem to persist it. I’ve tried a few
> different properties and none seem to stick. Do I need to flush the
> config somehow?
>
> I assume I can set these properties right after creating table only.
> I mean, what happens if I set a property like table.split.threshold
> after populating the table? There’s no command for setting these
> properties from accumulo shell other than the option to copy config
> from another table when executing create table.
>
> Thanks,
> Ara.
>
>
>
> ________________________________
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If
> you have received it in error, please notify the sender immediately
> and delete the original. Any other use of the e-mail by you is
> prohibited. Thank you in advance for your cooperation.
>
> ________________________________
>
>
Re: TableOperations.setProperty() not setting property
Posted by Mike Drob <md...@mdrob.com>.
Ara,
There is sometimes propogation delay in setting the properties, since they
have to go through zookeeper and then out to the tablet servers.
Try waiting 30 or 60 seconds before checking, and see if that changes
things.
Mike
On Thu, Jan 8, 2015 at 6:07 PM, Ara Ebrahimi <ar...@argyledata.com>
wrote:
> Hi,
>
> I’m trying to set a few properties for a table “programmatically” right
> after I create that table (using accumulo shell). I use
> TableOperations.setProperty(). But then when I use the config command from
> accumulo shell I don’t see anything reflected there. It still holds the old
> default/site values. If I pass invalid values it does fail, so seems like
> it actually receives the request and validates it. But it does’t seem to
> persist it. I’ve tried a few different properties and none seem to stick.
> Do I need to flush the config somehow?
>
> I assume I can set these properties right after creating table only. I
> mean, what happens if I set a property like table.split.threshold after
> populating the table? There’s no command for setting these properties from
> accumulo shell other than the option to copy config from another table when
> executing create table.
>
> Thanks,
> Ara.
>
>
>
> ________________________________
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you have
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited. Thank you in
> advance for your cooperation.
>
> ________________________________
>