hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Sigoure (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5204) Backward compatibility fixes for 0.92
Date Sat, 21 Jan 2012 09:12:40 GMT

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

Benoit Sigoure commented on HBASE-5204:
---------------------------------------

I agree with Zhihong.  Either this makes it into 0.92, or we just forget about it.

I talked to Stack and tried to argue that including this *completely harmless* change in 0.92
wouldn't require a new RC.  But apparently there's an Apache rule that you can't change a
single byte of the code without going through a new RC, so I gave up on the idea.

Including this change in trunk will cause confusion for future versions and will make my asynchbase's
life even more miserable than it is.  Yes Stack in theory I can rejigger the codes based on
what version of HBase I'm talking to, but in practice this I'd rather not do this.

It was a mistake to break the codes in the first place.  Either this mistake gets fixed right
now, in 0.92.0, or we just accept it and live with it and promise not to break them again
in the future.
                
> Backward compatibility fixes for 0.92
> -------------------------------------
>
>                 Key: HBASE-5204
>                 URL: https://issues.apache.org/jira/browse/HBASE-5204
>             Project: HBase
>          Issue Type: Bug
>          Components: ipc
>            Reporter: Benoit Sigoure
>            Assignee: Benoit Sigoure
>            Priority: Blocker
>              Labels: backwards-compatibility
>             Fix For: 0.92.0
>
>         Attachments: 0001-Add-some-backward-compatible-support-for-reading-old.patch,
0002-Make-sure-that-a-connection-always-uses-a-protocol.patch, 0003-Change-the-code-used-when-serializing-HTableDescript.patch,
5204-92.txt, 5204-trunk.txt, 5204.addendum
>
>
> Attached are 3 patches that are necessary to allow compatibility between HBase 0.90.x
(and previous releases) and HBase 0.92.0.
> First of all, I'm well aware that 0.92.0 RC4 has been thumbed up by a lot of people and
would probably wind up being released as 0.92.0 tomorrow, so I sincerely apologize for creating
this issue so late in the process.  I spent a lot of time trying to work around the quirks
of 0.92 but once I realized that with a few very quasi-trivial changes compatibility would
be made significantly easier, I immediately sent these 3 patches to Stack, who suggested I
create this issue.
> The first patch is required as without it clients sending a 0.90-style RPC to a 0.92-style
server causes the server to die uncleanly.  It seems that 0.92 ships with {{\-XX:OnOutOfMemoryError="kill
\-9 %p"}}, and when a 0.92 server fails to deserialize a 0.90-style RPC, it attempts to allocate
a large buffer because it doesn't read fields of 0.90-style RPCs properly.  This allocation
attempt immediately triggers an OOME, which causes the JVM to die abruptly of a {{SIGKILL}}.
 So whenever a 0.90.x client attempts to connect to HBase, it kills whichever RS is hosting
the {{\-ROOT-}} region.
> The second patch fixes a bug introduced by HBASE-2002, which added support for letting
clients specify what "protocol" they want to speak.  If a client doesn't properly specify
what protocol to use, the connection's {{protocol}} field will be left {{null}}, which causes
any subsequent RPC on that connection to trigger an NPE in the server, even though the connection
was successfully established from the client's point of view.  The fix is to simply give the
connection a default protocol, by assuming the client meant to speak to a RegionServer.
> The third patch fixes an oversight that slipped in HBASE-451, where a change to {{HbaseObjectWritable}}
caused all the codes used to serialize {{Writables}} to shift by one.  This was carefully
avoided in other changes such as HBASE-1502, which cleanly removed entries for {{HMsg}} and
{{HMsg[]}}, so I don't think this breakage in HBASE-451 was intended.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message