Re: phoenix client for web service using playframework

[Lian Jiang]

Never mind. http://phoenix.apache.org/server.html helps.

On Fri, Apr 20, 2018 at 9:13 PM, Lian Jiang  wrote:

> Hi,
>
> I am using HDP 2.6 hbase and pheonix. I created a play rest service using
> hbase as the backend. However, I have trouble to get a working pheonix
> client.
>
> I tried the pheonix-client.jar given by HDP but it has multiple conflicts
> with play, for example logback v.s. log4j,  guava 13 v.s. guava 22, etc.
>
> The logging exception is:
>
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in [jar:file:/Users/lianjia/repo/
> hbaseWS/lib/phoenix-client.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in [jar:file:/Users/lianjia/.ivy2
> /cache/ch.qos.logback/logback-classic/jars/logback-classic-1
> .2.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
> explanation.
>
> java.lang.ClassCastException: org.slf4j.impl.Log4jLoggerFactory cannot be
> cast to ch.qos.logback.classic.LoggerContext
> at play.api.libs.logback.LogbackLoggerConfigurator.configure(Lo
> gbackLoggerConfigurator.scala:84)
> at play.api.libs.logback.LogbackLoggerConfigurator.configure(Lo
> gbackLoggerConfigurator.scala:66)
> at play.api.inject.guice.GuiceApplicationBuilder.$anonfun$confi
> gureLoggerFactory$1(GuiceApplicationBuilder.scala:122)
> at scala.Option.map(Option.scala:146)
> at play.api.inject.guice.GuiceApplicationBuilder.configureLogge
> rFactory(GuiceApplicationBuilder.scala:121)
> at play.api.inject.guice.GuiceApplicationBuilder.applicationMod
> ule(GuiceApplicationBuilder.scala:100)
> at play.api.inject.guice.GuiceBuilder.injector(GuiceInjectorBui
> lder.scala:185)
> at play.api.inject.guice.GuiceApplicationBuilder.build(GuiceApp
> licationBuilder.scala:137)
> at play.api.inject.guice.GuiceApplicationLoader.load(GuiceAppli
> cationLoader.scala:21)
> at play.core.server.ProdServerStart$.start(ProdServerStart.scala:51)
> at play.core.server.ProdServerStart$.main(ProdServerStart.scala:25)
> at play.core.server.ProdServerStart.main(ProdServerStart.scala)
>
>
>
> Then I tried:
>
> libraryDependencies += "org.apache.phoenix" % "phoenix-core" %
> "4.13.1-HBase-1.1"
>
> libraryDependencies += "org.apache.phoenix" % "phoenix-server-client" %
> "4.7.0-HBase-1.1"
>
> libraryDependencies += "org.apache.phoenix" % "phoenix-queryserver-client"
> % "4.13.1-HBase-1.1"
>
> None of them worked: "No suitable driver found".
>
> Any idea will be highly appreciated!
>

Re: Split and distribute regions of SYSTEM.STATS table

[James Taylor]

For stats, what do you have your guidepost width set to? Do you only have a
single physical table? We've found that a value of 300MB still provides a
good enough granularity to get good bytes scanned estimates. We're
currently using an HBase API to update stats atomically. We could easily
make it splittable per column family per table if that's helpful. We could
also use the regular batch API and not have it be atomic (since stats are
just an estimate anyway). Please file a JIRA.

In theory, it would be fine to set IN_MEMORY to true, but there are a
couple of practical issues:
- You'll need the fix for PHOENIX-4579 or the property would be set back to
false when another client connects
- We already have client-side caching for stats and catalog and server-side
caching for catalog, so not sure how beneficial this would be.

Thanks,
James

On Sun, Apr 22, 2018 at 3:56 AM, Batyrshin Alexander <0x62...@gmail.com>
wrote:

> If all stats for given table should be on the same region there is no
> benefits on splitting.
>
> Another question: is it ok to set 'IN_MEMORY' => 'true' for CF of SYSTEM.*
> tables?
>
>
> On 20 Apr 2018, at 23:39, James Taylor  wrote:
>
> Thanks for bringing this to our attention. There's a bug here in that the
> SYSTEM.STATS table has a custom split policy that prevents splitting from
> occurring (PHOENIX-4700). We'll get a fix out in 4.14, but in the meantime
> it's safe to split the table, as long as all stats for a given table are on
> the same region.
>
> James
>
> On Fri, Apr 20, 2018 at 1:37 PM, James Taylor 
> wrote:
>
>> Thanks for bringing this to our attention. There's a bug here in that the
>> SYSTEM.STATS
>>
>> On Wed, Apr 18, 2018 at 9:59 AM, Batyrshin Alexander <0x62...@gmail.com>
>> wrote:
>>
>>>  Hello,
>>> I've discovered that SYSTEM.STATS has only 1 region with size 3.25 GB.
>>> Is it ok to split it and distribute over different region servers?
>>
>>
>>
>
>