Hi Josh,
thank you for replying.
This is an excerpt from the debug log:
the client can connected to Zookeeper successfully:
2018-08-01 10:21:15,987 [pool-1-thread-1] INFO
org.apache.phoenix.jdbc.PhoenixEmbeddedDriver$ConnectionInfo - Trying
to connect to a secure cluster as
I don't recall any big issues on 4.13.2, but I, admittedly, haven't
followed it closely.
You weren't doing anything weird on your own -- you wrote data via the
JDBC driver? Any index tables?
Aside from weirdness in the client with statistics, there isn't much
I've seen that ever causes a
Did you enable DEBUG logging on the client or server side? Certainly if
you got a connection timeout, you at least got a stack trace that you
could share.
You need to provide more information if you want help debugging your setup.
On 7/31/18 6:29 AM, anung wrote:
Hi All,
I have CDH 5.11
Please file a JIRA.
On Mon, Jul 30, 2018 at 10:12 PM, jie chen wrote:
> phoenix-4.14-hbase-1.2
>
> 0: jdbc:phoenix:localhost> create table test(id bigint not null primary
>>> key, a bigint);
>>
>> No rows affected (1.242 seconds)
>>
>> 0: jdbc:phoenix:localhost> upsert into test values(1,11);
Hi to all,
today I had a very weird, and potentially critical, behavior in my Phoenix
installation (4.13.2 on CDH 5.11.2).
I started upserting rows in a salted table but I fortunately discovered
that some of them were missing (and the PK was unique).
After 3 hours of attempts and debugging I gave
Hi All,
I have CDH 5.11 cluster (kerberized, but HBase is not yet secured),
installed Phoenix 4.14.0-cdh5.11.2 parcel method, test the JDBC
connection and succeed.
I can query, create table, drop table etc.
And then I enabling kerberos security in HBase, restart service, and
JDBC Phoenix is
phoenix-4.14-hbase-1.2
0: jdbc:phoenix:localhost> create table test(id bigint not null primary
>> key, a bigint);
>
> No rows affected (1.242 seconds)
>
> 0: jdbc:phoenix:localhost> upsert into test values(1,11);
>
> 1 row affected (0.01 seconds)
>
> 0: jdbc:phoenix:localhost> upsert into test
