Re: hotspot in System.catalog table

[anil gupta]

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 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 that, see here[1] and here[2].
>
> In the future, we'll let the SYSTEM.CATALOG table span multiple regions -
> keep an eye on PHOENIX-3534.
>
> Thanks,
> James
>
> [1] https://phoenix.apache.org/#Altering
> [2] https://phoenix.apache.org/language/index.html#options
>
> On Thu, Apr 12, 2018 at 10:32 PM, anil gupta 
> wrote:
>
>> 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
>> preparedstatement(contrary to Statement), system.catalog table is queried
>> first. Hence, it is resulting into hotspotting. Is my analysis correct?
>>
>> (I have already suggested my colleagues to try using Statement instead of
>> PS if they have to create a new one everytime.)
>>
>> --
>> Thanks & Regards,
>> Anil Gupta
>>
>
>


-- 
Thanks & Regards,
Anil Gupta

Re: hotspot in System.catalog table

[James Taylor]

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 that, see here[1] and here[2].

In the future, we'll let the SYSTEM.CATALOG table span multiple regions -
keep an eye on PHOENIX-3534.

Thanks,
James

[1] https://phoenix.apache.org/#Altering
[2] https://phoenix.apache.org/language/index.html#options

On Thu, Apr 12, 2018 at 10:32 PM, anil gupta  wrote:

> 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
> preparedstatement(contrary to Statement), system.catalog table is queried
> first. Hence, it is resulting into hotspotting. Is my analysis correct?
>
> (I have already suggested my colleagues to try using Statement instead of
> PS if they have to create a new one everytime.)
>
> --
> Thanks & Regards,
> Anil Gupta
>

hotspot in System.catalog table

[anil gupta]

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
preparedstatement(contrary to Statement), system.catalog table is queried
first. Hence, it is resulting into hotspotting. Is my analysis correct?

(I have already suggested my colleagues to try using Statement instead of
PS if they have to create a new one everytime.)

-- 
Thanks & Regards,
Anil Gupta

Re: Bind Params with Union throw AvaticaSqlException

[Lew Jackman]

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://thirdpartyoffers.netzero.net/TGL3231/5ad0085f8ab2385f473fst03vuc

Re: Bind Params with Union throw AvaticaSqlException

[Josh Elser]

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 wrote:

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=16293699#comment-16293699

When we turn up the debug logging, we find this:

java.lang.RuntimeException: java.sql.SQLException: ERROR 2004 (INT05): 
Parameter value unbound. Parameter at index 1 is unbound
org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:681)
org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:707)
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:208)
org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1195)
org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1166)
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:124)

Caused by: java.sql.SQLException: ERROR 2004 (INT05): Parameter value unbound. 
Parameter at index 1 is unbound
at 
org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:464)
at 
org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150)
at 
org.apache.phoenix.jdbc.PhoenixParameterMetaData.getParam(PhoenixParameterMetaData.java:89)
at 
org.apache.phoenix.jdbc.PhoenixParameterMetaData.isSigned(PhoenixParameterMetaData.java:138)
at org.apache.calcite.avatica.jdbc.JdbcMeta.parameters(JdbcMeta.java:267)
at org.apache.calcite.avatica.jdbc.JdbcMeta.signature(JdbcMeta.java:280)
at org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:701)
... 15 more

Re: Bind Params with Union throw AvaticaSqlException

[Lew Jackman]

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=16293699#comment-16293699

When we turn up the debug logging, we find this:

java.lang.RuntimeException: java.sql.SQLException: ERROR 2004 (INT05): 
Parameter value unbound. Parameter at index 1 is unbound
org.apache.calcite.avatica.jdbc.JdbcMeta.propagate(JdbcMeta.java:681)
org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:707)
org.apache.calcite.avatica.remote.LocalService.apply(LocalService.java:208)
org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1195)
org.apache.calcite.avatica.remote.Service$PrepareRequest.accept(Service.java:1166)
org.apache.calcite.avatica.remote.AbstractHandler.apply(AbstractHandler.java:95)
org.apache.calcite.avatica.remote.ProtobufHandler.apply(ProtobufHandler.java:46)
org.apache.calcite.avatica.server.AvaticaProtobufHandler.handle(AvaticaProtobufHandler.java:124)

Caused by: java.sql.SQLException: ERROR 2004 (INT05): Parameter value unbound. 
Parameter at index 1 is unbound
at 
org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:464)
at 
org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150)
at 
org.apache.phoenix.jdbc.PhoenixParameterMetaData.getParam(PhoenixParameterMetaData.java:89)
at 
org.apache.phoenix.jdbc.PhoenixParameterMetaData.isSigned(PhoenixParameterMetaData.java:138)
at org.apache.calcite.avatica.jdbc.JdbcMeta.parameters(JdbcMeta.java:267)
at org.apache.calcite.avatica.jdbc.JdbcMeta.signature(JdbcMeta.java:280)
at org.apache.calcite.avatica.jdbc.JdbcMeta.prepare(JdbcMeta.java:701)
... 15 more



After Weeks Of Rumors, Joanna Gaines Comes Clean
risingstarnewspaper.com
http://thirdpartyoffers.netzero.net/TGL3231/5acfc66fd1278466f5e0dst02vuc

Re: KrbException: Checksum failed when attempting connection to PQS

[Pedro Boado]

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 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;serialization
> =PROTOBUF;authentication=SPNEGO;principal=HTTP/x@y
> ;keytab=/etc/security/keytabs/spnego.service.keytab
>
> Using phoenix-queryserver-client-4.13.1-HBase-1.2.jar.   Note this only
> happens with JDBC connection;  if we run kinit, sqlline.py can connect on
> the localhost.
>
> JDK 1.8
> HBase 1.2.0
> Hadoop 2.7.2
> avatica-core-1.10.0.jar, avatica-metrics-1.10.0.jar, sqlline-1.2.0.jar
>
> Exception when connection:
>
> ```2018-04-12 10:41:52,665 WARN
> org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService:
> GSSException: Failure unspecified at GSS-API level (Mechanism level:
> Checksum failed)
> at
> sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)
> at
> sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
> at
> sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> at
> sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:906)
> at
> sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:556)
> at
> sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
> at
> sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService.login(SpnegoLoginService.java:137)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.LoginAuthenticator.login(LoginAuthenticator.java:61)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.SpnegoAuthenticator.validateRequest(SpnegoAuthenticator.java:99)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:512)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.server.Server.handle(Server.java:499)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
> at
> org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: KrbException: Checksum failed
> at
> sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:102)
> at
> sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:94)
> at sun.security.krb5.EncryptedData.decrypt(EncryptedData.java:175)
> at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
> at sun.security.krb5.KrbApReq.(KrbApReq.java:149)
> at
> sun.security.jgss.krb5.InitSecContextToken.(InitSecContextToken.java:108)
> at
> sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:829)
> ... 19 more
> Caused by: java.security.GeneralSecurityException: Checksum failed
> at
> sun.security.krb5.internal.crypto.dk.ArcFourCrypto.decrypt(ArcFourCrypto.java:408)
> at
> sun.security.krb5.internal.crypto.ArcFourHmac.decrypt(ArcFourHmac.java:91)
> at
> sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:100)
> ... 25 more```
>
>

KrbException: Checksum failed when attempting connection to PQS

[Yan Koyfman]

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;serialization
=PROTOBUF;authentication=SPNEGO;principal=HTTP/x@y
;keytab=/etc/security/keytabs/spnego.service.keytab

Using phoenix-queryserver-client-4.13.1-HBase-1.2.jar.   Note this only
happens with JDBC connection;  if we run kinit, sqlline.py can connect on
the localhost.

JDK 1.8
HBase 1.2.0
Hadoop 2.7.2
avatica-core-1.10.0.jar, avatica-metrics-1.10.0.jar, sqlline-1.2.0.jar

Exception when connection:

```2018-04-12 10:41:52,665 WARN
org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService:
GSSException: Failure unspecified at GSS-API level (Mechanism level:
Checksum failed)
at
sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:856)
at
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
at
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
at
sun.security.jgss.spnego.SpNegoContext.GSS_acceptSecContext(SpNegoContext.java:906)
at
sun.security.jgss.spnego.SpNegoContext.acceptSecContext(SpNegoContext.java:556)
at
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
at
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
at
org.apache.phoenix.shaded.org.eclipse.jetty.security.SpnegoLoginService.login(SpnegoLoginService.java:137)
at
org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.LoginAuthenticator.login(LoginAuthenticator.java:61)
at
org.apache.phoenix.shaded.org.eclipse.jetty.security.authentication.SpnegoAuthenticator.validateRequest(SpnegoAuthenticator.java:99)
at
org.apache.phoenix.shaded.org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:512)
at
org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
at
org.apache.phoenix.shaded.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at
org.apache.phoenix.shaded.org.eclipse.jetty.server.Server.handle(Server.java:499)
at
org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at
org.apache.phoenix.shaded.org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.apache.phoenix.shaded.org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at
org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.apache.phoenix.shaded.org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
Caused by: KrbException: Checksum failed
at
sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:102)
at
sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:94)
at sun.security.krb5.EncryptedData.decrypt(EncryptedData.java:175)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)
at sun.security.krb5.KrbApReq.(KrbApReq.java:149)
at
sun.security.jgss.krb5.InitSecContextToken.(InitSecContextToken.java:108)
at
sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:829)
... 19 more
Caused by: java.security.GeneralSecurityException: Checksum failed
at
sun.security.krb5.internal.crypto.dk.ArcFourCrypto.decrypt(ArcFourCrypto.java:408)
at
sun.security.krb5.internal.crypto.ArcFourHmac.decrypt(ArcFourHmac.java:91)
at
sun.security.krb5.internal.crypto.ArcFourHmacEType.decrypt(ArcFourHmacEType.java:100)
... 25 more```