avro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: Using Avro with something like OSGi or NetBeans RCP; modular Java systems dealing with classloader separation
Date Mon, 21 Feb 2011 16:42:58 GMT
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 Chandler
Software Engineer and Developer
NetBeans Dream Team Member and Contributor


----- Original Message ----
> From: Doug Cutting <cutting@apache.org>
> To: user@avro.apache.org
> 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 
> > 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 
> > from available providers, restart the server.  Clients will have a period of 
> > 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 
> > how the client protocols which were  merged on the server would react to 
> > Perhaps it isn't a big deal  if some how versions are the same and the 
> > 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

View raw message