hadoop-common-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Hadoop Wiki] Update of "Release1.0Requirements" by SanjayRadia
Date Wed, 08 Oct 2008 16:52:55 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Hadoop Wiki" for change notification.

The following page has been changed by SanjayRadia:
http://wiki.apache.org/hadoop/Release1%2e0Requirements

------------------------------------------------------------------------------
  
  ''I think for 1.0 we should not switch Hadoop's RPC mechanism.  That is a good change to
target for 2.0, when the RPC landscape is clearer.  Language-neutral protocols also mean duplicated
client-side logic which brings considerable complication.'' --DougCutting
  
+ ''I wasn't suggesting changing the RPC protoocol but merely the layer above the rpc protocol
- the rpc type system and/or serialization.
+ For example, protocol buffers lets you use your own transport. So may thrift. I would also
like to wait till a good rpc solution is available. However I would like to understand what
you think is missing in the current RPC landscape? Are there specific features that you see
missing in some of the rpc solutions or are you waiting for CISCO's Etch solution to make
a decision. Etch looks very attractive on the surface. I am also torn by this decision because
it seems worth waiting till Etch is published before making our decision. It would help if
you could elaborate on your thoughts on the rpc issue. --SanjayRadia''
+ 
+ 
+ 
  === Versioning Scheme - Manual or Automated ===
  Hadoop is likely to see fairly significant changes between 1.0 and 2.0. Given the compatibility
requirements, we need some scheme (manual or automated) for versioning the RPC interfaces
and also for versioning the data types that are passed as parameters to rpc.
  
@@ -62, +67 @@

  
  For 1.0 we should not switch Hadoop's RPC mechanism. That is a good change to target for
2.0, when the RPC landscape is clearer.  We have very specific performance needs for RPC that
these other mechanisms do not yet support. -DougCutting''
  
+ 
+ 
  === RPC server that's forward-friendly ===
  
     * RPC mechanism should be able to detect and throw exception on new methods that old
servers clearly don't implement.
  
+ 
  ''That could be added in 1.1, no?  I don't see this as a 1.0 requirement, but maybe I'm
missing something.  What happens today when you call an undefined method?  Protocol version
mismatch, probably.  --DougCutting''
  
- ''Strictly speaking, this can wait till 1.1 but we have to be sure that we can do it.  Most
rpc systems do this as part of its spec and  not as an afterthought. Given that it is easy
to do I would prefer to do it for 1.0''.
+ ''Strictly speaking, this can wait till 1.1 but we have to be sure that we can do it.  Most
rpc systems do this as part of its spec and  not as an afterthought. Given that it is easy
to do I would prefer to do it for 1.0 -- SanjayRadia.''
  
  == Release 2.0 Requirements ==
  

Mime
View raw message