phoenix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thangamani, Arun" <Arun.Thangam...@cdk.com>
Subject Re: Write path blocked by MetaDataEndpoint acquiring region lock
Date Mon, 09 May 2016 20:02:04 GMT
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<mailto:jamestaylor@apache.org>>
Reply-To: "user@phoenix.apache.org<mailto:user@phoenix.apache.org>" <user@phoenix.apache.org<mailto:user@phoenix.apache.org>>
Date: Monday, May 9, 2016 at 10:18 AM
To: user <user@phoenix.apache.org<mailto: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<mailto:ndimiduk@apache.org>>
wrote:
On Mon, May 9, 2016 at 12:06 AM, James Taylor <jamestaylor@apache.org<mailto: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