hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-14904) Mark Base[En|De]coder LimitedPrivate and fix binary compat issue
Date Wed, 02 Dec 2015 19:02:11 GMT

     [ https://issues.apache.org/jira/browse/HBASE-14904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Enis Soztutar updated HBASE-14904:
    Attachment: hbase-14904_v2.patch

Attaching rebased v2. 

[~apurtell] what do you think about this one? The binary compat issue only affects Phoenix
(only known WALCellCodec implementation outside HBase). We can re-break the binary compat
between 0.98.16 and 0.98.17. We did not do any 1.x release yet with  HBASE-14501. 

> Mark Base[En|De]coder LimitedPrivate and fix binary compat issue
> ----------------------------------------------------------------
>                 Key: HBASE-14904
>                 URL: https://issues.apache.org/jira/browse/HBASE-14904
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.3, 0.98.17, 1.0.4
>         Attachments: hbase-14904_v1.patch, hbase-14904_v2.patch
> PHOENIX-2477 revealed that the changes from HBASE-14501 breaks binary compatibility in
Phoenix compiled with earlier versions of HBase and run agains later versions. 
> This is one of the areas that the boundary is not clear, but it won't hurt us to fix
> The exception trace is: 
> {code}
> Exception in thread "main" java.lang.NoSuchFieldError: in
> 	at org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec$PhoenixBaseDecoder.<init>(IndexedWALEditCodec.java:106)
> 	at org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec$IndexKeyValueDecoder.<init>(IndexedWALEditCodec.java:121)
> 	at org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec.getDecoder(IndexedWALEditCodec.java:63)
> 	at org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader.initAfterCompression(ProtobufLogReader.java:292)
> 	at org.apache.hadoop.hbase.regionserver.wal.ReaderBase.init(ReaderBase.java:82)
> 	at org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader.init(ProtobufLogReader.java:148)
> 	at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:316)
> 	at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:281)
> 	at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:269)
> 	at org.apache.hadoop.hbase.wal.WALFactory.createReader(WALFactory.java:418)
> 	at org.apache.hadoop.hbase.wal.WALPrettyPrinter.processFile(WALPrettyPrinter.java:247)
> 	at org.apache.hadoop.hbase.wal.WALPrettyPrinter.run(WALPrettyPrinter.java:422)
> 	at org.apache.hadoop.hbase.wal.WALPrettyPrinter.main(WALPrettyPrinter.java:357)
> {code}
> Although {{BaseDecoder.in}} is still there, it got changed to be a class rather than
an interface. BaseDecoder is marked Private, thus the binary compat check is not run at all.
Not sure whether it would have caught this. 

This message was sent by Atlassian JIRA

View raw message