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 <jamestay...@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.thangam...@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 <jamestay...@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 <ndimi...@apache.org> wrote: >> >>> On Mon, May 9, 2016 at 12:06 AM, James Taylor <jamestay...@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. >> > >
