[jira] [Created] (PHOENIX-4896) Phoenix Kafka Plugin java.lang.NoSuchMethodError
XiaoMifan created PHOENIX-4896:
--
Summary: Phoenix Kafka Plugin java.lang.NoSuchMethodError
Key: PHOENIX-4896
URL: https://issues.apache.org/jira/browse/PHOENIX-4896
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.14.0
Environment: EMR 5.16.0
Hive 2.3.3,
Pig 0.17.0,
Spark 2.3.1,
Phoenix 4.14.0,
HBase 1.4.4,
Tez 0.8.4,
ZooKeeper 3.4.12
Kakfa 1.1.0-cp1 (Confluent Open Source)
Reporter: XiaoMifan
I'm trying to run Kafka Plugin under EMR 5.16 environment, seems lot of
dependencies are missing, I added follows to solved some of the NoClassFound
errors.
{code:java}
commons-io-2.4.jar
disruptor-2.7.1.jar
json-20090211.jar
json-path-2.2.0.jar
{code}
But for this one, it's still could not be solved:
{code:java}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in
[jar:file:/usr/lib/hadoop/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/home/ec2-user/apache-flume-1.8.0-bin/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/usr/lib/phoenix/phoenix-4.14.0-HBase-1.4-client.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/usr/lib/phoenix/phoenix-4.14.0-HBase-1.4-hive.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/usr/lib/phoenix/phoenix-4.14.0-HBase-1.4-pig.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in
[jar:file:/usr/lib/phoenix/phoenix-4.14.0-HBase-1.4-thin-client.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
Exception in thread "main" com.google.common.util.concurrent.ExecutionError:
java.lang.NoSuchMethodError:
com.lmax.disruptor.dsl.Disruptor.(Lcom/lmax/disruptor/EventFactory;ILjava/util/concurrent/ThreadFactory;Lcom/lmax/disruptor/dsl/ProducerType;Lcom/lmax/disruptor/WaitStrategy;)V
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2232)
at com.google.common.cache.LocalCache.get(LocalCache.java:3965)
at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4764)
at
org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:241)
at
org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:150)
at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:221)
at java.sql.DriverManager.getConnection(DriverManager.java:664)
at java.sql.DriverManager.getConnection(DriverManager.java:208)
at
org.apache.phoenix.flume.serializer.BaseEventSerializer.initialize(BaseEventSerializer.java:140)
at
org.apache.phoenix.kafka.consumer.PhoenixConsumer.start(PhoenixConsumer.java:195)
at
org.apache.phoenix.kafka.consumer.PhoenixConsumer.(PhoenixConsumer.java:75)
at
org.apache.phoenix.kafka.consumer.PhoenixConsumerTool.run(PhoenixConsumerTool.java:98)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:90)
at
org.apache.phoenix.kafka.consumer.PhoenixConsumerTool.main(PhoenixConsumerTool.java:104)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.hadoop.util.RunJar.run(RunJar.java:234)
at org.apache.hadoop.util.RunJar.main(RunJar.java:148)
Caused by: java.lang.NoSuchMethodError:
com.lmax.disruptor.dsl.Disruptor.(Lcom/lmax/disruptor/EventFactory;ILjava/util/concurrent/ThreadFactory;Lcom/lmax/disruptor/dsl/ProducerType;Lcom/lmax/disruptor/WaitStrategy;)V
at
org.apache.phoenix.log.QueryLoggerDisruptor.(QueryLoggerDisruptor.java:72)
at
org.apache.phoenix.query.ConnectionQueryServicesImpl.(ConnectionQueryServicesImpl.java:414)
at org.apache.phoenix.jdbc.PhoenixDriver$3.call(PhoenixDriver.java:248)
at org.apache.phoenix.jdbc.PhoenixDriver$3.call(PhoenixDriver.java:241)
at
com.google.common.cache.LocalCache$LocalManualCache$1.load(LocalCache.java:4767)
at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3568)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2350)
at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2313)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2228)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (PHOENIX-4895) NoClassDefFound when use IndexTool create async index
张延召 created PHOENIX-4895: Summary: NoClassDefFound when use IndexTool create async index Key: PHOENIX-4895 URL: https://issues.apache.org/jira/browse/PHOENIX-4895 Project: Phoenix Issue Type: Bug Affects Versions: 5.0.0 Environment: HDP ：3.0.0 HBase :2.0.0 Phoenix ： 5.0.0 Hadoop ： 3.1.0 Reporter: 张延召 Fix For: 5.1.0 First I created a table ^CREATE TABLE TMP_TEST(^ ^ID VARCHAR NOT NULL PRIMARY KEY,^ ^NAME VARCHAR,^ ^ADDR VARCHAR,^ ^AGE BIGINT DEFAULT 10^ ^);^ Then I created the asynchronous index table ^CREATE INDEX ASYNC_IDX ON TMP_TEST (NAME, ADDR) INCLUDE (AGE) ASYNC;^ Finally, perform the MapReduce Task ^./hbase org.apache.phoenix.mapreduce.index.IndexTool --schema default --data-table TMP_TEST --index-table ASYNC_IDX --output-path ASYNC_IDX_HFILES^ But I received an error message ^Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/cli/DefaultParser^ ^at org.apache.phoenix.mapreduce.index.IndexTool.parseOptions(IndexTool.java:183)^ ^at org.apache.phoenix.mapreduce.index.IndexTool.run(IndexTool.java:522)^ ^at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)^ ^at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:90)^ ^at org.apache.phoenix.mapreduce.index.IndexTool.main(IndexTool.java:769)^ ^Caused by: java.lang.ClassNotFoundException: org.apache.commons.cli.DefaultParser^ ^at java.net.URLClassLoader.findClass(URLClassLoader.java:381)^ ^at java.lang.ClassLoader.loadClass(ClassLoader.java:424)^ ^at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)^ ^at java.lang.ClassLoader.loadClass(ClassLoader.java:357)^ ^... 5 more^ Please give me some advice，Thanks -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4858) Add PHOENIX-3655 PQS Client Metrics documentation
[ https://issues.apache.org/jira/browse/PHOENIX-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved PHOENIX-4858. - Resolution: Fixed > Add PHOENIX-3655 PQS Client Metrics documentation > - > > Key: PHOENIX-4858 > URL: https://issues.apache.org/jira/browse/PHOENIX-4858 > Project: Phoenix > Issue Type: Improvement >Reporter: Karan Mehta >Assignee: Karan Mehta >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4858.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4884) INSTR function should work seamlessly with literal and non-literal arguments
[
https://issues.apache.org/jira/browse/PHOENIX-4884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-4884:
Attachment: PHOENIX-4884.004.patch
> INSTR function should work seamlessly with literal and non-literal arguments
>
>
> Key: PHOENIX-4884
> URL: https://issues.apache.org/jira/browse/PHOENIX-4884
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4884.001.patch, PHOENIX-4884.002.patch,
> PHOENIX-4884.003.patch, PHOENIX-4884.004.patch
>
>
> INSTR's documentation reads as though it should support an expression or a
> literal for either argument. At least, it doesn't say that it only supports
> one or the other.
> However, the implementation only handles the case of {{INSTR(expr,
> literal)}}. We can pretty easily make this better and work with any
> combination:
> e.g. {{INSTR(literal, expr)}}, {{INSTR(expr, expr)}}, {{INSTR(literal,
> literal)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Salting based on partial rowkeys
Hello folks, We have a requirement for salting based on partial, rather than full, rowkeys. My colleague Mike Polcari has identified the requirement and proposed an approach. I found an already-open JIRA ticket for the same issue: https://issues.apache.org/jira/browse/PHOENIX-4757. I can provide more details from the proposal. The JIRA proposes a syntax of SALT_BUCKETS(col, ...) = N, whereas Mike proposes SALT_COLUMN=col or SALT_COLUMNS=col, ... . The benefit at issue is that users gain more control over partitioning, and this can be used to push some additional aggregations and hash joins down to region servers. I would appreciate any go-ahead / thoughts / guidance / objections / feedback. I'd like to be sure that the concept at least is not objectionable. We would like to work on this and submit a patch down the road. I'll also add a note to the JIRA ticket. Thanks, Gerald
Re: Salting based on partial rowkeys
Hey Gerald, Trimming back to just dev@phoenix, but I am curious to hear some more about what you and Mike are thinking. Some initial questions: * What are the problem(s) that you see today with the current implementation of SALT_BUCKETS * How would your new feature/proposal work? * How would your new feature solve your current problem? * What are the drawbacks (if any) of your new feature? I've definitely seen a problem where folks negatively impact their reads by "over-salting" because they were too lazy when writing data (either to think about a good distribution or to write some code to ingest their data). Thanks in advance! - Josh On 9/10/18 4:56 PM, Gerald Sangudi wrote: Hello folks, We have a requirement for salting based on partial, rather than full, rowkeys. My colleague Mike Polcari has identified the requirement and proposed an approach. I found an already-open JIRA ticket for the same issue: https://issues.apache.org/jira/browse/PHOENIX-4757. I can provide more details from the proposal. The JIRA proposes a syntax of SALT_BUCKETS(col, ...) = N, whereas Mike proposes SALT_COLUMN=col or SALT_COLUMNS=col, ... . The benefit at issue is that users gain more control over partitioning, and this can be used to push some additional aggregations and hash joins down to region servers. I would appreciate any go-ahead / thoughts / guidance / objections / feedback. I'd like to be sure that the concept at least is not objectionable. We would like to work on this and submit a patch down the road. I'll also add a note to the JIRA ticket. Thanks, Gerald
[jira] [Updated] (PHOENIX-4858) Add PHOENIX-3655 PQS Client Metrics documentation
[ https://issues.apache.org/jira/browse/PHOENIX-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karan Mehta updated PHOENIX-4858: - Attachment: PHOENIX-4858.001.patch > Add PHOENIX-3655 PQS Client Metrics documentation > - > > Key: PHOENIX-4858 > URL: https://issues.apache.org/jira/browse/PHOENIX-4858 > Project: Phoenix > Issue Type: Improvement >Reporter: Karan Mehta >Assignee: Karan Mehta >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4858.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4428) Trace details can't be shown in the Phoenix Tracing Web Application
[
https://issues.apache.org/jira/browse/PHOENIX-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas D'Silva resolved PHOENIX-4428.
-
Resolution: Duplicate
Thanks [~willshen]. I made you a contributor, so you should be able to assign
issues and duplicate etc now.
> Trace details can't be shown in the Phoenix Tracing Web Application
> ---
>
> Key: PHOENIX-4428
> URL: https://issues.apache.org/jira/browse/PHOENIX-4428
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.13.0
>Reporter: Alex Chistyakov
>Priority: Major
> Attachments: Screen Shot 2017-12-01 at 18.34.07.png, Screen Shot
> 2017-12-01 at 18.34.12.png
>
>
> A timeline or a dependency tree can't be shown for a trace.
> {code}
> 298752 [qtp440434003-46] WARN org.eclipse.jetty.servlet.ServletHandler -
> /trace/
> java.lang.RuntimeException: The passed parentId/traceId is not a number.
> at
> org.apache.phoenix.tracingwebapp.http.TraceServlet.searchTrace(TraceServlet.java:117)
> at
> org.apache.phoenix.tracingwebapp.http.TraceServlet.doGet(TraceServlet.java:67)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:648)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:559)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:365)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:926)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:988)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:627)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:51)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NumberFormatException: null
> at java.lang.Long.parseLong(Long.java:552)
> at java.lang.Long.parseLong(Long.java:631)
> at
> org.apache.phoenix.tracingwebapp.http.TraceServlet.searchTrace(TraceServlet.java:114)
> ... 26 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4671) Fix minor size accounting bug for MutationSize
[ https://issues.apache.org/jira/browse/PHOENIX-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Batyrshin updated PHOENIX-4671: Comment: was deleted (was: I've checked [https://github.com/apache/phoenix/blob/4.14-HBase-1.4/phoenix-core/src/main/java/org/apache/phoenix/execute/MutationState.java] and found that line numbers mismatch in MutationState.java with stack trace So i've checked previous version [https://github.com/apache/phoenix/blob/14baca9ded1d68a97c1f559806fa34dfe8c9415e/phoenix-core/src/main/java/org/apache/phoenix/execute/MutationState.java] and lines completely match. is this normal? Why git branch '4.14-HBase-1.4' point not to sources that distributed?) > Fix minor size accounting bug for MutationSize > -- > > Key: PHOENIX-4671 > URL: https://issues.apache.org/jira/browse/PHOENIX-4671 > Project: Phoenix > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Minor > Fix For: 4.14.0, 5.0.0 > > Attachments: 4671-v2.txt, 4671.txt > > > Just ran into a bug where UPSERT INTO table ... SELECT ... FROM table would > fail due to "Error: ERROR 730 (LIM02): MutationState size is bigger than > maximum allowed number of bytes (state=LIM02,code=730)" even with auto commit > on. > Ran it through a debugger, just a simple accounting bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4428) Trace details can't be shown in the Phoenix Tracing Web Application
[
https://issues.apache.org/jira/browse/PHOENIX-4428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Shen updated PHOENIX-4428:
--
Comment: was deleted
(was: Saw the fix here:
[https://github.com/apache/phoenix/commit/b9ed1398d91ed140315f52014b4aee9783f6d965]
Any interest to merge the fix in?)
> Trace details can't be shown in the Phoenix Tracing Web Application
> ---
>
> Key: PHOENIX-4428
> URL: https://issues.apache.org/jira/browse/PHOENIX-4428
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.13.0
>Reporter: Alex Chistyakov
>Priority: Major
> Attachments: Screen Shot 2017-12-01 at 18.34.07.png, Screen Shot
> 2017-12-01 at 18.34.12.png
>
>
> A timeline or a dependency tree can't be shown for a trace.
> {code}
> 298752 [qtp440434003-46] WARN org.eclipse.jetty.servlet.ServletHandler -
> /trace/
> java.lang.RuntimeException: The passed parentId/traceId is not a number.
> at
> org.apache.phoenix.tracingwebapp.http.TraceServlet.searchTrace(TraceServlet.java:117)
> at
> org.apache.phoenix.tracingwebapp.http.TraceServlet.doGet(TraceServlet.java:67)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:648)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:559)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1072)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:382)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1006)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
> at org.eclipse.jetty.server.Server.handle(Server.java:365)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:485)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:926)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:988)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:635)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:627)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:51)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NumberFormatException: null
> at java.lang.Long.parseLong(Long.java:552)
> at java.lang.Long.parseLong(Long.java:631)
> at
> org.apache.phoenix.tracingwebapp.http.TraceServlet.searchTrace(TraceServlet.java:114)
> ... 26 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
