Unfortunately, no.  

Our application needs to be able to be able to callback multiple times for a 
single request.  To support this we need to 1) propagate callbacks all the way 
to the server.  Currently, though the code generator creates two interfaces for 
each message (synchronous and asynchronous), the asynchronous version is never 
called by the Responder.  And 2) the server can't remove request callbacks from 
the requests table (in the NettyTransceiver) until it has received the last 
response message.

So in our branch, we added 2 flags to each message: isBlockingRequest (i.e. 
call the blocking implementation instead of the non-blocking implementation) 
and isLastPacket.

To make the schema specification more intuitive we also added a new type: 
"callback<ReturnType>", which can be used to indicate that this message is 
meant to be asynchronous.

I realize this is a fairly big change, and I'm not sure if the community is 
interested.  At any rate I'm preparing a patch now and will be submitting it 
soon.

I couldn't figure out a way to do this with plugins, but please let me know if 
you have any ideas.

-Shaun

On Dec 12, 2011, at 1:35 PM, Doug Cutting wrote:

> On 12/01/2011 11:43 AM, Shaun Williams wrote:
>> Can anyone tell me what the implications are to chaining the transport
>> codec in the NettyTransportCodec, e.g. adding a additional flag?  Do the
>> rpc implementations in any of the other languages support this codec
>> currently?  Is there anything it might break?
> 
> I think the Netty transport is compatible with the (deprecated)
> SocketServer and SocketTransceiver.  I think most languages include an
> HTTP-based implementation, not a socket-based implementation.  The
> preferred socket implementation is SaslSocketTransceiver.
> 
> It would be simple to convert the Netty implementation to be compatible
> with SaslSocketTransceiver for the anonymous mechanism:
> 
> http://avro.apache.org/docs/current/sasl.html#anonymous
> 
> Also, is there a way you might add the flag to the request or response
> metadata, perhaps with an RPC plugin?
> 
> Doug

Reply via email to