Thanks much Doug, I will check it out and get back to you once I get something prototyped using the ideas. I might have more questions, but will first try to understand the specifics. Makes sense from the top though.
Thanks again, Wade ================== Wade Chandler Software Engineer and Developer NetBeans Dream Team Member and Contributor http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org ----- Original Message ---- > From: Doug Cutting <[email protected]> > To: [email protected] > Sent: Fri, February 18, 2011 7:18:33 PM > Subject: Re: Using Avro with something like OSGi or NetBeans RCP; modular > Java >systems dealing with classloader separation > > 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 >
