We are attempting to create a connection to PQS (Phoenix 4.13.1) in a
Kerberized Hbase cluster, but have been running into the following
exception. Is there something we should start with to troubleshoot?
Thanks.
Our connection string looks like this:
jdbc:phoenix:thin:url=http://xxx:8765;ser
Just to discard it. Might you need Java Unlimited Cryptography Extension to
be installed to deal with the cipher algorithms in your keytabs?
On Thu, 12 Apr 2018, 20:47 Yan Koyfman, wrote:
> We are attempting to create a connection to PQS (Phoenix 4.13.1) in a
> Kerberized Hbase cluster, but have
Thanks for the recommendation Josh.
This looks like our issue:
https://issues.apache.org/jira/browse/PHOENIX-4450?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=16293699#comment-16293699
When we turn up the debug logging, we find this:
java.lang.Runtime
Any chance you can share the complete stacktrace you see as well as the
version of Phoenix that you're using, Lew?
This code bridges Phoenix and Avatica -- having line numbers and a
version of code to compare against will help get to the bottom of the issue.
On 4/12/18 4:48 PM, Lew Jackman wr
This is Phoenix 4.9, we are upgrading to 4.11 very shortly but are on 4.9 this
week.
I'll try to get a better stack trace, thanks much
World War 2 Discovery Kept Secret For Over 70 Years?!
pro.naturalhealthresponse.com
http://thirdparty
Hi All,
System.catalog table seems to be single region table(correct?). We are
currently facing a problem of hotspot on System.catalog table.
One of our app does around 4-5k select queries/sec. And, It is creating a
new preparedstatement everytime. I suspect that while instantiating a new
prepared
Try setting the UPDATE_CACHE_FREQUENCY table property (and configuring
the phoenix.default.update.cache.frequency system-wide property). That'll
prevent pinging the region hosting SYSTEM.CATALOG every time a query is
compiled. We've found value of even 5 seconds makes a big difference. For
more on
Thanks for quick reply, James. We will look into UPDATE_CACHE_FREQUENCY
property. If we just replace PS with Statement, will it fix the
problem(AFAIK, Statement is not compiled)?
On Thu, Apr 12, 2018 at 10:43 PM, James Taylor
wrote:
> Try setting the UPDATE_CACHE_FREQUENCY table property (and co
No, that won’t make a difference.
On Thu, Apr 12, 2018 at 10:51 PM anil gupta wrote:
> Thanks for quick reply, James. We will look into UPDATE_CACHE_FREQUENCY
> property. If we just replace PS with Statement, will it fix the
> problem(AFAIK, Statement is not compiled)?
>
> On Thu, Apr 12, 2018 a
I c. As per documentation[1], even for commits of upsert system.catalog is
called. IMO, ALWAYS seems to be really aggressive. Is there any reason
UPDATE_CACHE_FREQUENCY is set to ALWAYS by default? Do we plan to change
the default value to 5 or 10 sec? Thanks for your help.
PS: we were running in
I have set phoenix.default.update.cache.frequency=6 in hbase-site.xml
via ambari(we barely alter schema). Is this a client or server side
property?
On Thu, Apr 12, 2018 at 11:14 PM, anil gupta wrote:
> I c. As per documentation[1], even for commits of upsert system.catalog is
> called. IMO,
It’s client side, but that’ll only impact newly created tables. You’ll need
to use the ALTER TABLE command for existing tables.
On Thu, Apr 12, 2018 at 11:30 PM anil gupta wrote:
> I have set phoenix.default.update.cache.frequency=6 in hbase-site.xml
> via ambari(we barely alter schema). Is
Thanks a lot. Going to do that and see the impact.
On Thu, Apr 12, 2018 at 11:33 PM, James Taylor
wrote:
> It’s client side, but that’ll only impact newly created tables. You’ll
> need to use the ALTER TABLE command for existing tables.
>
> On Thu, Apr 12, 2018 at 11:30 PM anil gupta wrote:
>
>
13 matches
Mail list logo
