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