Thanks Doug & Jeff, Jeff I read link you provided. Does this mean that the current RPC implementation will be deprecated once AVRO-341 has been finished? What is the time frame for AVRO-341? Is it planned for the 1.4 release? For now I'm just going to get something out that support connection pooling.
Haha a more important question would be when is the 1.4 release planned? The .net port is coming along nicely and should be ready for an alpha release in the near future after I do some interop testing. RPC is a feature that I want to have Doug That makes much more sense to me now. Thank you! The plugin implementation makes a lot of sense. I'll implement something similar with the .net version. On a side note I'm thinking I'll be ready for an alpha release pretty soon. When would you consider accepting a patch? https://issues.apache.org/jira/browse/AVRO-533 is the issue I am working against. The patch that is out there is quite old so I'll need to generate a new one. J On Tue, Jun 8, 2010 at 11:37 AM, Doug Cutting <[email protected]> wrote: > 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 >>> >>> >>
