Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # user >> schema handshake using HTTP headers


Copy link to this message
-
Re: schema handshake using HTTP headers
One of the reasons why HTTP was chosen for the reference RPC was because it
can be made proxy friendly.

Please open a JIRA on this issue to discuss.  If you have an approach that
is already in progress, submit a patch!  Apache is a 'do-ocrocy'.

I suspect there will be some discussion about backwards compatibility and
the spec, but the experts on Avro RPC will have more to contribute to that
discussion.

Thanks,

-Scott
On 8/24/11 9:39 AM, "Shafi, Saleem" <[EMAIL PROTECTED]> wrote:

> Hello all,
>  
> We¹re experimenting a bit with Avro and we¹ve got a use case that I¹m hoping
> to get some help with..  we¹d like clients to be able to send messages to a
> server that would then forward the messages to a third-party (still in Avro),
> but the messaging would be asynchronous..  the trouble we¹re running into is
> with the schema handshake since there¹s someone between the client and the
> ultimate recipient of the message..  we¹d like to avoid having the middle-man
> open up the body of the HTTP request but we can¹t negotiate the handshake
> without it..
>  
> Since the transport is abstracted out, would it make any sense at all to push
> the handshake request into HTTP headers for the HTTP transport?  Other
> transports could still embed the handshake message with the rest of the
> message, but by pushing the handshake into the headers for HTTP, a proxy like
> ours could negotiate the handshake without opening up the body..  this could
> arguably improve performance even in normal request/response scenarios since
> the body wouldn¹t have to be parsed twice in cases where the client has to
> resend the request with a new schema..
>  
> If this seems like a reasonable approach, we might be able to put together an
> prototype implementation with one of the bindings and see if it makes sense to
> adjust the spec..
>  
> Thanks,
> Saleem.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB