On this thread from last year, are there any further pointers on using
websockets as the transport layer for Avro?

FromConnor Doyle <[EMAIL PROTECTED]>SubjectRe: Avro RPCDateWed, 29
May 2013 18:36:31 GMT

In the parlance of the relevant section of the Avro specification
("Protocol Wire Format"),
I'm talking about a stateful connection.  The agreed-upon client and
server protocol versions
are part of the connection state, as are the pending requests at each
client.  By tagging
each request with a sequence number we can allow responses to roll in
asynchronously.  We
encode this identifier as an Avro long in the metadata map sent with
each message, as laid
out in the spec for the call format.  In our case, we're using a web
socket connection as
the transport layer.

On May 29, 2013, at 12:50, Mark <[EMAIL PROTECTED]> wrote:

on your use case?
connection.  We use binary avro RPC over a WebSocket connection.  The
overhead for each request
is a tiny blob of metadata and the message name.  This compares very
favorably with a full
set of HTTP headers for each message.  Another advantage we see is
that with a persistent
connection we can handle responses asynchronously; quickly serviced
requests don't have to
wait for slow ones.  It all depends on the details of your use case, however.
something like a simple restful service over HTTP?
and slightly more compact. Other than that, I'm drawing a blank. As
far as the response goes
though, couldn't you simply return an Avro message from a restful http
service and have the
client parse it if you wanted more structure?

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