phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Dimiduk <ndimi...@gmail.com>
Subject Re: Write path blocked by MetaDataEndpoint acquiring region lock
Date Thu, 26 May 2016 01:35:31 GMT
Hi James,

I'm not sure that tweaking UPDATE_CACHE_FREQUENCY is the right solution.
Certainly it's not a complete solution. After spending some time reading
code, I've opened a couple JIRAs related to this thread.

https://issues.apache.org/jira/browse/PHOENIX-2939
https://issues.apache.org/jira/browse/PHOENIX-2940
https://issues.apache.org/jira/browse/PHOENIX-2941

I think I've happened into a couple of unrelated problems that interacted
badly amongst themselves.

Thanks a lot,
Nick

On Mon, May 9, 2016 at 3:05 PM, James Taylor <jamestaylor@apache.org> wrote:

> 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