On 02/18/2011 01:16 PM, Wade Chandler wrote: > I have had different thoughts. I'm wanting to use as much of Avro which is > already available as possible. The top two seem to be: > > 1) Write my own server implementation which handles multiple responders.
This seems like a sub-optimal approach. > 2) Write a responder implementation which takes multiple providers and builds > a > unified protocol to be parsed. This sounds better to me. You might be able to use SpecificResponder directly if you construct a java.lang.reflect.Proxy that implements all of the module interfaces and whose InvocationHandler dispatches to the appropriate module implementation. So this might look something like: public static Object createProxy(Class[] interfaces, Object[] impls); This proxy could then be passed to SpecificResponder as the implementation. You'd then also need to construct a protocol that appends the messages of all of the modules. Note however that with this approach no two modules could contain messages of the same name. > When modules are perhaps live updated in the > server send some message telling all clients that connections must be > reconnected unless the updates require client updates which can force them to > restart in which case they need to reconnect anyways. After this message has > been sent out, close all connections from the server side, rebuild the > protocol > from available providers, restart the server. Clients will have a period of > time > before they timeout after trying once receiving the message. Could you simply restart the server, closing all client connections when they complete their currently executing request, without sending any special message to the clients? Then the clients would simply need to be written to retry requests when they get a connection closed exception. > The snag here seems to be on the client side. It isn't straight forward > exactly > how the client protocols which were merged on the server would react to this. > Perhaps it isn't a big deal if some how versions are the same and the records > and messages match up. Not sure exactly as I'm just beginning. The responder doesn't currently check that the client and server protocol names match, so this should mostly just work. The only problem I see is if two protocols have a message with the same name (as mentioned above). If you need to permit that, then you couldn't use the proxy approach above, but would need to use a responder that wraps or extends SpecificResponder and dispatches to the right implementation instance based on the protocol name, not just the message name. The client's protocol name is available through a ThreadLocal as Responder.getRemote(). Hope this helps! Doug
