phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <>
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?


On Mon, May 9, 2016 at 1:02 PM, Thangamani, Arun <>

> 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 <>
> Reply-To: "" <>
> Date: Monday, May 9, 2016 at 10:18 AM
> To: user <>
> Subject: Re: Write path blocked by MetaDataEndpoint acquiring region lock
> On Mon, May 9, 2016 at 9:52 AM, Nick Dimiduk <> wrote:
>> On Mon, May 9, 2016 at 12:06 AM, James Taylor <>
>> 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
> Thanks,
> James
> [1]
> <>
> ------------------------------
> 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.

View raw message