Re: Cannot access from jdbc

[Nicolas Paris]

I solved the problem.
I added the hbase-site.xml file found on the cluster in my java classpath,
added few lines for kerberos access also.

Both helped.

Thanks,

2018-05-23 19:56 GMT+02:00 Josh Elser :

> Try enabling DEBUG logging for HBase and take a look at the RegionServer
> log identified by the hostname in the log message.
>
> Most of the time when you see this error, it's a result of HBase rejecting
> the incoming request for a Kerberos authentication issue.
>
>
> On 5/23/18 12:10 PM, Nicolas Paris wrote:
>
>> hi team
>>
>> I am having this error while trying to connect from a java program to a
>> working phoenix 4.7 (hdp build) instance:
>>
>>
>>   Wed May 23 16:40:56 CEST 2018, null, java.net.SocketTimeoutException:
>> callTimeout=6, callDuration=69037:
>>   Call to /: failed on local exception:
>> java.io.IOException: Connection reset by peer row 'SYSTEM:CATALOG,,'
>>   on table 'hbase:meta' at region=hbase:meta,,1.1588230740,
>> hostname=,,1526661975419, seqNum=0
>>
>> The hbase is securized with kerberos, and the whole is managed by
>> zookeeper.
>>
>> Any insight on this behavior ?
>>
>> Thanks a lot,
>>
>>
>>
>>
>>

Re: Cannot access from jdbc

[Josh Elser]

Try enabling DEBUG logging for HBase and take a look at the RegionServer 
log identified by the hostname in the log message.


Most of the time when you see this error, it's a result of HBase 
rejecting the incoming request for a Kerberos authentication issue.


On 5/23/18 12:10 PM, Nicolas Paris wrote:

hi team

I am having this error while trying to connect from a java program to a working 
phoenix 4.7 (hdp build) instance:


  Wed May 23 16:40:56 CEST 2018, null, java.net.SocketTimeoutException: 
callTimeout=6, callDuration=69037:
  Call to /: failed on local exception: java.io.IOException: 
Connection reset by peer row 'SYSTEM:CATALOG,,'
  on table 'hbase:meta' at region=hbase:meta,,1.1588230740, 
hostname=,,1526661975419, seqNum=0

The hbase is securized with kerberos, and the whole is managed by zookeeper.

Any insight on this behavior ?

Thanks a lot,

Re: Cannot access from jdbc

[Nicolas Paris]

Agreed James

Thanks !

2018-05-23 18:40 GMT+02:00 James Taylor :

> Hi Nicolas,
> I don't think it's fair to ask the Apache Phoenix community to investigate
> a vendor specific issue from a more than two year old forked repo. I have
> no idea which of the 912 JIRAs since Phoenix 4.7.0 made it into that fork.
>
> Thanks,
> James
>
> On Wed, May 23, 2018 at 9:26 AM, Nicolas Paris 
> wrote:
>
>> Hi James.
>>
>> I tried to make the update myself but without success.
>> This actualy a custom 4.7 version (here the commit log
>> https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.1/bk_
>> release-notes/content/patch_phoenix.html)
>> The commit log looks more recent than 2 years
>>
>>
>> 2018-05-23 18:16 GMT+02:00 James Taylor :
>>
>>> The 4.7 release is more than two years old. That's seven releases back
>>> from the current release we're voting on 4.14. I'd recommend working with
>>> your vendor and urging them to upgrade to a newer, supportable version.
>>>
>>> Thanks,
>>> James
>>>
>>> On Wed, May 23, 2018 at 9:10 AM, Nicolas Paris 
>>> wrote:
>>>
 hi team

 I am having this error while trying to connect from a java program to a 
 working phoenix 4.7 (hdp build) instance:


  Wed May 23 16:40:56 CEST 2018, null, java.net.SocketTimeoutException: 
 callTimeout=6, callDuration=69037:
  Call to /: failed on local exception: 
 java.io.IOException: Connection reset by peer row 'SYSTEM:CATALOG,,'
  on table 'hbase:meta' at region=hbase:meta,,1.1588230740, 
 hostname=,,1526661975419, seqNum=0

 The hbase is securized with kerberos, and the whole is managed by 
 zookeeper.

 Any insight on this behavior ?

 Thanks a lot,





>>>
>>
>

Re: Cannot access from jdbc

[James Taylor]

Hi Nicolas,
I don't think it's fair to ask the Apache Phoenix community to investigate
a vendor specific issue from a more than two year old forked repo. I have
no idea which of the 912 JIRAs since Phoenix 4.7.0 made it into that fork.

Thanks,
James

On Wed, May 23, 2018 at 9:26 AM, Nicolas Paris  wrote:

> Hi James.
>
> I tried to make the update myself but without success.
> This actualy a custom 4.7 version (here the commit log
> https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.1/
> bk_release-notes/content/patch_phoenix.html)
> The commit log looks more recent than 2 years
>
>
> 2018-05-23 18:16 GMT+02:00 James Taylor :
>
>> The 4.7 release is more than two years old. That's seven releases back
>> from the current release we're voting on 4.14. I'd recommend working with
>> your vendor and urging them to upgrade to a newer, supportable version.
>>
>> Thanks,
>> James
>>
>> On Wed, May 23, 2018 at 9:10 AM, Nicolas Paris 
>> wrote:
>>
>>> hi team
>>>
>>> I am having this error while trying to connect from a java program to a 
>>> working phoenix 4.7 (hdp build) instance:
>>>
>>>
>>>  Wed May 23 16:40:56 CEST 2018, null, java.net.SocketTimeoutException: 
>>> callTimeout=6, callDuration=69037:
>>>  Call to /: failed on local exception: java.io.IOException: 
>>> Connection reset by peer row 'SYSTEM:CATALOG,,'
>>>  on table 'hbase:meta' at region=hbase:meta,,1.1588230740, 
>>> hostname=,,1526661975419, seqNum=0
>>>
>>> The hbase is securized with kerberos, and the whole is managed by zookeeper.
>>>
>>> Any insight on this behavior ?
>>>
>>> Thanks a lot,
>>>
>>>
>>>
>>>
>>>
>>
>

Re: Cannot access from jdbc

[Nicolas Paris]

Hi James.

I tried to make the update myself but without success.
This actualy a custom 4.7 version (here the commit log
https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.1/bk_release-notes/content/patch_phoenix.html
)
The commit log looks more recent than 2 years


2018-05-23 18:16 GMT+02:00 James Taylor :

> The 4.7 release is more than two years old. That's seven releases back
> from the current release we're voting on 4.14. I'd recommend working with
> your vendor and urging them to upgrade to a newer, supportable version.
>
> Thanks,
> James
>
> On Wed, May 23, 2018 at 9:10 AM, Nicolas Paris 
> wrote:
>
>> hi team
>>
>> I am having this error while trying to connect from a java program to a 
>> working phoenix 4.7 (hdp build) instance:
>>
>>
>>  Wed May 23 16:40:56 CEST 2018, null, java.net.SocketTimeoutException: 
>> callTimeout=6, callDuration=69037:
>>  Call to /: failed on local exception: java.io.IOException: 
>> Connection reset by peer row 'SYSTEM:CATALOG,,'
>>  on table 'hbase:meta' at region=hbase:meta,,1.1588230740, 
>> hostname=,,1526661975419, seqNum=0
>>
>> The hbase is securized with kerberos, and the whole is managed by zookeeper.
>>
>> Any insight on this behavior ?
>>
>> Thanks a lot,
>>
>>
>>
>>
>>
>

Re: Cannot access from jdbc

[James Taylor]

The 4.7 release is more than two years old. That's seven releases back from
the current release we're voting on 4.14. I'd recommend working with your
vendor and urging them to upgrade to a newer, supportable version.

Thanks,
James

On Wed, May 23, 2018 at 9:10 AM, Nicolas Paris  wrote:

> hi team
>
> I am having this error while trying to connect from a java program to a 
> working phoenix 4.7 (hdp build) instance:
>
>
>  Wed May 23 16:40:56 CEST 2018, null, java.net.SocketTimeoutException: 
> callTimeout=6, callDuration=69037:
>  Call to /: failed on local exception: java.io.IOException: 
> Connection reset by peer row 'SYSTEM:CATALOG,,'
>  on table 'hbase:meta' at region=hbase:meta,,1.1588230740, 
> hostname=,,1526661975419, seqNum=0
>
> The hbase is securized with kerberos, and the whole is managed by zookeeper.
>
> Any insight on this behavior ?
>
> Thanks a lot,
>
>
>
>
>

Cannot access from jdbc

[Nicolas Paris]

hi team

I am having this error while trying to connect from a java program to
a working phoenix 4.7 (hdp build) instance:


 Wed May 23 16:40:56 CEST 2018, null, java.net.SocketTimeoutException:
callTimeout=6, callDuration=69037:
 Call to /: failed on local exception:
java.io.IOException: Connection reset by peer row 'SYSTEM:CATALOG,,'
 on table 'hbase:meta' at region=hbase:meta,,1.1588230740,
hostname=,,1526661975419, seqNum=0

The hbase is securized with kerberos, and the whole is managed by zookeeper.

Any insight on this behavior ?

Thanks a lot,