Example 2 looks right to me. Metadata is out-of-band data, not provided
directly by client applications or seen directly by server-side
implementations. It's intended to be useful for implementing call
tracing, performance statistics, session management, etc. The client
and server runtime might provide hooks that permit plugins to process
metadata.
For example, Java has an RPCPlugin interface:
http://avro.apache.org/docs/current/api/java/org/apache/avro/ipc/RPCPlugin.html
An implementation of this is provided that records server-side RPC
statistics:
http://avro.apache.org/docs/current/api/java/org/apache/avro/ipc/stats/StatsPlugin.html
Doug
On 06/07/2010 06:23 PM, Jeremy Custenborder wrote:
Thanks Doug,
That affirms the direction that I was heading. Should I assume that metadata
is unique to each message? Here is what I have done so far for the code
generator portion. Should I worry about generating code that looks like
example 1 where I pass along a dictionary for metadata? Or should I look at
something like example 2 where I don't pass along the metadata. I could also
do a combination of both.
Example 1
[System.CodeDom.Compiler.GeneratedCodeAttribute("Avro.CodeGen.AvroGen",
"1.0")]
public interface Simple
{
///<summary>
/// Send a greeting
///</summary>
string hello(System.Collections.Generic.IDictionary<string, byte[]>
metadata, string greeting);
///<summary>
/// Pretend you're in a cave!
///</summary>
TestRecord echo(System.Collections.Generic.IDictionary<string,
byte[]> metadata, TestRecord record);
int add(System.Collections.Generic.IDictionary<string, byte[]>
metadata, int arg1, int arg2);
byte[] echoBytes(System.Collections.Generic.IDictionary<string,
byte[]> metadata, byte[] data);
///<summary>
/// Always throws an error.
///</summary>
void error(System.Collections.Generic.IDictionary<string, byte[]>
metadata);
}
Example 2
[System.CodeDom.Compiler.GeneratedCodeAttribute("Avro.CodeGen.AvroGen",
"1.0")]
public interface Simple
{
///<summary>
/// Send a greeting
///</summary>
string hello(string greeting);
///<summary>
/// Pretend you're in a cave!
///</summary>
TestRecord echo(TestRecord record);
int add(int arg1, int arg2);
byte[] echoBytes(byte[] data);
///<summary>
/// Always throws an error.
///</summary>
void error();
}
On Mon, Jun 7, 2010 at 5:03 PM, Doug Cutting<[email protected]> wrote:
On 06/07/2010 02:25 PM, Jeremy Custenborder wrote:
This will be my last question for at least the next day or two. :) I just
want to double check my interpretation of the message framing.
Framing is mostly orthogonal to payload structure. It just says that the
bytes that make up a payload are broken into length-prefixed frames. Those
frames may or may not align with the payload's structure. When they do line
up, optimizations are possible, so implementations should try to line them
up when sending largish binary objects.
Request payloads are of the form<metadata><messageName><parameters> and
response payloads are of the form<metadata><boolean><errorOrResponse>.
These may be delivered in one or more frames. A good framing might be to
use a single frame unless a parameter has a bytes value that's larger than
4k, in which case that buffer might be transmitted as a distinct frame, so
that it can be potentially processed in zerocopy style. I.e., if it
contains file data, then the sendfile system call could be used to copy data
from file to socket.
Does that help?
Doug
