Re: Phoenix Multi-Tenancy

[Eli Levine]

Hi Sudipta,

This is a good high-level overview of Phoenix’s multi-tenancy: https://
phoenix.apache.org/multi-tenancy.html

Are you looking for more info than what’s on that page?

CC’ing user@phoenix, since this might be useful to others.

Thanks,

Eli


On Wed, Oct 4, 2017 at 10:28 PM, sudipta das  wrote:

> Hello Eli,
>
> I have got your mail id while searching more details on Phoenix
> Multi-Tenancy.
> I am looking for how multi-tenancy works ?
>
> Can you please share some details ?
>
> Thanks,
> Sudipta
>

Re: Cannot connect phoenix client in kerberos cluster

[Mallieswari Dineshbabu]

Hi rafa,
I have this Kernel32 error in normal hadoop cluster also but i can
successfully to connected with the query server using sqlline-thin.py. In
kerberos cluster the ,I getting following error.
java.lang.RuntimeException: Failed to execute HTTP Request, got HTTP/404
at
org.apache.calcite.avatica.remote.AvaticaCommonsHttpClientSpnegoImpl.send(AvaticaCommonsHttpClientSpnegoImpl.java:148)
at
org.apache.calcite.avatica.remote.DoAsAvaticaHttpClient$1.run(DoAsAvaticaHttpClient.java:40)
at
org.apache.calcite.avatica.remote.DoAsAvaticaHttpClient$1.run(DoAsAvaticaHttpClient.java:38)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at
org.apache.calcite.avatica.remote.DoAsAvaticaHttpClient.send(DoAsAvaticaHttpClient.java:38)
at
org.apache.calcite.avatica.remote.RemoteProtobufService._apply(RemoteProtobufService.java:45)
at
org.apache.calcite.avatica.remote.ProtobufService.apply(ProtobufService.java:81)
at org.apache.calcite.avatica.remote.Driver.connect(Driver.java:176)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:270)
at multiaccess.Jobs.PhoenixJava(Jobs.java:69)
at multiaccess.Jobs.executeQueries(Jobs.java:39)
at multiaccess.MultiAccess$1.call(MultiAccess.java:61)
at multiaccess.MultiAccess$1.call(MultiAccess.java:56)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

Note: Phoenix Package Version- 4.11.0-Hbase-1.2
Hbase Version- 4.2.5
Hadoop version- 2.7.2


Please help me to connect with query server through sqlline-thin client

Regards,
Mallieswari D

On Thu, Oct 5, 2017 at 7:01 PM, rafa  wrote:

> Hi,
>
> The method 1 should work as far as the query server connects to the
> cluster successfully with the configured keytab. It seems a classpath
> problem on client side:
>
> [ERROR] Terminal initialization failed; falling back to unsupported
>
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.phoenix.sh
> aded.org.fusesource.jansi.internal.Kernel32
>
> I have no exprience with windows. Seems that there is need for jline in
> the classpath
>
> https://jline.github.io/
>
> check this:
>
> https://issues.apache.org/jira/browse/HIVE-13824
>
> regards
>
>
> On Thu, Oct 5, 2017 at 2:29 PM, Mallieswari Dineshbabu <
> dmalliesw...@gmail.com> wrote:
>
>> Yes, It is installed in all the JVMs. Any other solution.
>>
>>
>> On Wed, Oct 4, 2017 at 5:30 PM, rafa  wrote:
>>
>>> Hi Mallieswari,
>>>
>>> Perhaps the Java Cryptography Extension (JCE) Unlimited Strength
>>> Jurisdiction Policy Files are not installed in all the JVMs ?
>>>
>>> Regards,
>>> rafa
>>>
>>> On Wed, Oct 4, 2017 at 1:18 PM, Mallieswari Dineshbabu <
>>> dmalliesw...@gmail.com> wrote:
>>>
 Hi ,



 I have configured a phoenix package "apache-phoenix-4.11.0-HBase-1.2-bin"
 to Hbase version "1.2.5" in kerberos cluster.



 For phoenix secure cluster configuration, I have added the following
 properties into the *hbase-site.xml* present in *phoenix/bin* along
 with the properties of hbase configuration properties present in hbase/conf
 path and refer the *core-site.xml*, *hdfs-site.xml* file in
 phoenix/bin path



 phoenix.queryserver.keytab.file

 The key to look for keytab file.

 *unset*

 phoenix.queryserver.kerberos.principal

 The kerberos principal to use when authenticating.

 *unset*

 Phoenix Query Server:



 Once updated a above properties query server has been started
 successfully using keytab.



 *Command to Server:*

 *python queryserver.py*



 Phoenix Client:



 Once the query server is started successfully then the port no 8765
 comes to live. When i try to connect client with following command it
 returns GSS Exception. Am I missing any steps in configuration.





 *Command to Client:*

 Following are the methods i tried to connect in secure cluster it does
 not works.



 *Method 1:* python sqlline-thin.py http://hostname:8765

 *Method 2:*

 python sqlthin-client.py http://hostname:8765;authentic
 ation=SPNEGO;principal=phoenix/org...@xx.x.com;keyta
 b=C:\\path\\to\\HadoopKeyTabs\\\phoenix.keytab
 





 *CLIENT SIDE ERROR:*

 x-4.11.0-HBase-1.2-bin\bin>python sqlline-thin.py http://namenode1:8765

 Failed to find hbase executable on PATH, defaulting 

Re: Async get

[Jonathan Leech]

I agree here but will go farther. Hbase needs an asynchronous api that goes 
further than its current capability, for example like building lamda functions 
in the client tier that execute in a java streams manner. Being able to run 
mapping functions, aggregations, etc without needing coprocessors would be a 
big win. If Hbase doesn’t do it, the next thing will.

> On Oct 5, 2017, at 11:31 AM, James Taylor  wrote:
> 
> I do think it would be good for Phoenix to have a netty-based async means of 
> interacting with the server. We've found that to really drive down latency 
> for a parallelized query over a big cluster, you have to have a ridiculously 
> large thread pool on the client side (4000 threads for cluster with 100s of 
> nodes). A netty-based means of interacting would allow us to drive down the 
> latency without resorting to this (though this is pure conjecture at this 
> point - we might run into other, unknown scaling constraints through an async 
> API). Asynchbase, however, has a lot of restrictions in terms of how you can 
> interact with the server. If it could become part of HBase and support the 
> full wire protocol, then it might be an option.
> 
> Thanks,
> James
> 
>> On Thu, Oct 5, 2017 at 7:00 AM, Flavio Pompermaier  
>> wrote:
>> Maybe Phoenix could benefit from https://github.com/OpenTSDB/asynchbase, 
>> what do you think?
>> 
>>> On Thu, Oct 5, 2017 at 12:03 AM, Kevin Liew  wrote:
>>> Wrapping a thread-blocking call in a Future makes it asynchronous, but does 
>>> not turn it into a non-blocking call.
>>> 
>>> https://www.google.ca/amp/blog.colinbreck.com/calling-blocking-code-there-is-no-free-lunch/amp/
>>> 
 On Wed, Oct 4, 2017 at 11:36 AM Stan Campbell  
 wrote:
 Wrap the call in a Future.  You're home.
 
 
> On Wed, Oct 4, 2017, 9:36 AM James Taylor  wrote:
> Hi Flavio,
> Phoenix supports JDBC. The implementation may do gets, scans, etc., but 
> it's completely transparent to the user.
> Thanks,
> James
> 
>> On Wed, Oct 4, 2017 at 6:36 AM, Flavio Pompermaier 
>>  wrote:
>> Hi to all,
>> does Phoenix support async get? I can't find anything about this..
>> 
>> Best,
>> Flavio
> 
>> 
>