I think this would work for us. We would have to maintain two separate protocols, server and client, which is fine. I'm wondering, however, if we could make the relationship between the two explicit in the protocol definition, e.g. extend messages to support taking a protocol as a parameter (or otherwise attach a response protocol to a message). The getRequestor() method could then return a requestor within the context of a message.
Also, I may be mistaken, but the Netty implementation already supports AVRO-625. It writes a serial id before each request/response, and then stores callbacks to the requestor in a table by the serial id. Once a response is received, the callback is removed from the table. -Shaun On Dec 13, 2011, at 9:29 AM, Doug Cutting wrote: > On 12/12/2011 05:11 PM, Shaun Williams wrote: >> Our application needs to be able to be able to callback multiple times for a >> single request. > > That doesn't sounds like a traditional call/response pattern. > > Perhaps this would better be modeled as one-way messages. Host A would > send a one-way message to host B indicating its interest in responses, > then the B would send those responses as one-way messages, terminating > these with a special end-of-response message. In Avro this would > currently require two connections, one A->B and another B->A. > > But one might extend things so that a server could make requests back to > the client over the same connection. For example, the metadata that > precedes requests and responses might include a "Message-Type" > parameter, with values "Request" and "Response". This might be combined > with my proposal in AVRO-625 (http://s.apache.org/ASH), so these headers > are only valid when both client and server also specify "Call-Id" in > their metadata. In that case the client already needs to dispatch > responses to callers and it might thus also be extended to dispatch > requests. > > The server-side API might be a static method Responder.getRequestor() > that can only be called while responding and returns a Requestor for > calls back to the client. Client-side, one would construct one's > Requestor with a Responder that it would use to respond to requests from > the server. > > Or maybe its simpler to just use two connections! > > Does that make any sense? > > Doug
