You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2016/01/28 02:55:39 UTC

[jira] [Comment Edited] (PHOENIX-2636) Figure out a work around for java.lang.NoSuchFieldError: in when compiling against HBase < 0.98.17

    [ https://issues.apache.org/jira/browse/PHOENIX-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15120576#comment-15120576 ] 

Andrew Purtell edited comment on PHOENIX-2636 at 1/28/16 1:55 AM:
------------------------------------------------------------------

No, our internal version is 0.98.16 plus Enis's patch, so there is no prevention of any upgrading. We should talk more in house. :-)

Edit: Also, you may or may not be aware our internal version of Phoenix is harmonized with the HBase version and all components in the stack are recompiled against each other for every release. We found the ClassCastException in release validation, cherry picked the fix from upstream, and proceeded without further incident. Coprocessors should be thought of like Linux kernel modules and managed the same way. 

I would also suggest because of the decoupled nature of the whole Hadoop ecosystem and pace of change, binary convenience artifacts are not really that convenient. HBase binary artifacts are of limited utility as they ship because it's probable the user is running a different version of Hadoop than the default for the build. This is true to some extent up and down the stack. Some projects resort to shims. I think the whole ecosystem would ultimately do users a favor by switching to source only releases. It won't happen but it should. Let Apache Bigtop handle the heavy lifting of producing sets of binary artifacts known to integrate cleanly. 


was (Author: apurtell):
No, our internal version is 0.98.16 plus Enis's patch, so there is no prevention of any upgrading. We should talk more in house. :-)

> Figure out a work around for java.lang.NoSuchFieldError: in when compiling against HBase < 0.98.17
> --------------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-2636
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2636
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Samarth Jain
>            Assignee: Samarth Jain
>            Priority: Critical
>
> Working on PHOENIX-2629 revealed that when compiling against an HBase version prior to 0.98.17 and running against 0.98.17, region assignments fails to complete because of the error:
> {code}
> java.lang.NoSuchFieldError: in
> 	at org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec$PhoenixBaseDecoder.<init>(IndexedWALEditCodec.java:111)
> 	at org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec$IndexKeyValueDecoder.<init>(IndexedWALEditCodec.java:126)
> 	at org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec.getDecoder(IndexedWALEditCodec.java:68)
> 	at org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader.initAfterCompression(ProtobufLogReader.java:253)
> 	at org.apache.hadoop.hbase.regionserver.wal.ReaderBase.init(ReaderBase.java:86)
> 	at org.apache.hadoop.hbase.regionserver.wal.HLogFactory.createReader(HLogFactory.java:129)
> 	at org.apache.hadoop.hbase.regionserver.wal.HLogFactory.createReader(HLogFactory.java:91)
> 	at org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getReader(HLogSplitter.java:668)
> 	at org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getReader(HLogSplitter.java:577)
> 	at org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:282)
> 	at org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:225)
> 	at org.apache.hadoop.hbase.regionserver.SplitLogWorker$1.exec(SplitLogWorker.java:143)
> 	at org.apache.hadoop.hbase.regionserver.handler.HLogSplitterHandler.process(HLogSplitterHandler.java:82)
> 	at org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:129)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)