avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thiruvalluvan M. G." <thiru...@yahoo.com>
Subject RE: RPC multiplexing
Date Tue, 09 Feb 2010 13:55:24 GMT
Doug Cutting wrote:

> Requiring servers to copy the call-id to responses 
> is an incompatible change.  So is adding a magic number.

Do we want to introduce these incompatible changes in 1.3? If yes, I can
file a JIRA and work on it. In 1.3 we can just introduce the simple
(synchronous) client and server.

Since the servers should anyway respect call-id, shall we also say that
every request should have a call-id. The simple (synchronous) client may
send the same id for every request. Since, with a synchronous client, there
won't be more than one request outstanding at any given point in time,
sending the same call-id is fine. This simplifies the protocol as there are
no conditional elements in the request. This proposal makes the current
client and server incompatible. Doug's original proposal makes only the
server incompatible.

What do you think?

Thiru

-----Original Message-----
From: Doug Cutting [mailto:cutting@apache.org] 
Sent: Wednesday, January 06, 2010 1:26 AM
To: avro-dev@hadoop.apache.org
Subject: Re: RPC multiplexing

Philip Zeyliger wrote:
> Thinking out loud, the handshake could negotiate not just the schema for
the
> protocol, but also the schema for the RPC metadata.

So we'd send a hash of the handshake's schema too?  I think sending a 
magic number is equivalent and simpler.

> Is the call-id value arbitrary bytes?  We wouldn't break compatibility
with
> what's currently published if the server was allowed to not set call-id if
> it was responding to things in order.

Yes, you're right.  Requiring servers to copy the call-id to responses 
is an incompatible change.  So is adding a magic number.  But the spec 
currently does not yet define any transports, only request and response 
messages, which do not change.  So we can consider this requirement and 
the addition of a magic number as a part of the specification of a 
TCP-based transport and label the existing implementation non-conforming.

Doug


Mime
View raw message