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



 ==================
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 <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 
>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
> 

Mime
View raw message