phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: Write path blocked by MetaDataEndpoint acquiring region lock
Date Mon, 09 May 2016 22:05:24 GMT
bq. But, using UPDATE_CACHE_FREQUENCY restricts the usage of a
changing-schema table in production.

You can still alter tables in production. It's just that a client on a
different JVM won't see the schema changes until their cache expires. If
only schema additions are being performed, we can do even better
(see PHOENIX-2885).

Does this meet your needs, Arun & Nick?

Thanks,
James

On Mon, May 9, 2016 at 1:02 PM, Thangamani, Arun <Arun.Thangamani@cdk.com>
wrote:

> Sorry, I haven’t had the chance to test the UPDATE_CACHE_FREQUENCY
> parameter yet, we are behind on phoenix versions through our vendor.
> So, I am a little restricted in testing this out. But, will find a way to
> test soon.
>
> Overall though, I do believe supporting client controlled timestamp
> upserts with random timestamps (going forward or backward in time) would be
> a fundamental use case.
>
> Right now, theoretically, the only way we can support this - without
> running into the row lock issue — is by defining UPDATE_CACHE_FREQUENCY.
> But, using UPDATE_CACHE_FREQUENCY restricts the usage of a changing-schema
> table in production.
>
> In my case, the table didn’t change much, so I might be ok for now like
> James pointed out, but we can use a new JIRA to address this issue in the
> long run.
>
> Thanks
> Arun
>
> From: James Taylor <jamestaylor@apache.org>
> Reply-To: "user@phoenix.apache.org" <user@phoenix.apache.org>
> Date: Monday, May 9, 2016 at 10:18 AM
> To: user <user@phoenix.apache.org>
> Subject: Re: Write path blocked by MetaDataEndpoint acquiring region lock
>
> On Mon, May 9, 2016 at 9:52 AM, Nick Dimiduk <ndimiduk@apache.org> wrote:
>
>> On Mon, May 9, 2016 at 12:06 AM, James Taylor <jamestaylor@apache.org>
>> wrote:
>>
>>> Have you tried using the UPDATE_CACHE_FREQUENCY property [1] I mentioned
>>> before?
>>>
>>
>> I am still running 4.6, so this flag is not available to me at the
>> moment. It is unacceptable to disable updates to this cache; I do
>> infrequently add columns to my tables. This does not change my position on
>> the cache update happening under rowlock.
>>
>
> I'm hoping that the UPDATE_CACHE_FREQUENCY property will provide a quick,
> practical solution to the problem. We're, of course, always open to patches
> and contributions.
>
>
>>
>> Would be good to file a JIRA if you haven't already, and continue the
>>> discussion there.
>>>
>>
>> Arun already filed PHOENIX-2607. Do you believe his issue is different
>> from what I'm experiencing?
>>
>
> Based on Arun's comment[1], it sounds like phoenix.stats.useCurrentTime
> and UPDATE_CACHE_FREQUENCY solved his immediate issue. If there are bigger,
> architectural changes you'd like to discuss/contribute, let's open a new
> JIRA.
>
> Thanks,
> James
>
> [1]
> https://issues.apache.org/jira/browse/PHOENIX-2607?focusedCommentId=15146319&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15146319
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_PHOENIX-2D2607-3FfocusedCommentId-3D15146319-26page-3Dcom.atlassian.jira.plugin.system.issuetabpanels-3Acomment-2Dtabpanel-23comment-2D15146319&d=DQMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=8g2kPpY-h3f5UtWTI1wWrWsWv9dLqY7DoaD5gi4GbNk&m=VcOngVZBlhLdrPlPtPTAKbgJG8JkbuqBBHznBeGalSY&s=-kBM8n6j3QOqV-t8yKNfLiR-2IvkO9EO1YNNyFnpDgk&e=>
>
> ------------------------------
> This message and any attachments are intended only for the use of the
> addressee and may contain information that is privileged and confidential.
> If the reader of the message is not the intended recipient or an authorized
> representative of the intended recipient, you are hereby notified that any
> dissemination of this communication is strictly prohibited. If you have
> received this communication in error, notify the sender immediately by
> return email and delete the message and any attachments from your system.
>

Mime
View raw message