RE: [JBoss-dev] Remoting Invokers commit

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

One of the things Tom and I are talking about is updating the locator
URI to have the path portion of the URI contain an actual remote object
reference (something like an IOR) which would allow you to resolve an
object right down to the object path itself.  This of course would mean
different things for different subsystems.  For example, for a JMX
subsystem, it could be an ObjectName.  It could be a GUID for other
subsystems that dynamically created objects (maybe AOP).  

The power of this is that you could basically build a locator directly
to an object for invocation, vs. just the location of the remote
connector.  Put a ActivationIntercptor in front of this on the remote
side, and you could very easy build activaction services which
automagically create services/objects/EJBs, etc. on the fly based on
activation policies.

Not much changes to make this work since the locator URI already has the
path attribute - its just not currently being used on either end.

-----Original Message-----
From: jbo...@li...
[mailto:jbo...@li...] On Behalf Of
David Jencks
Sent: Friday, April 25, 2003 10:57 PM
To: jbo...@li...
Subject: RE: [JBoss-dev] Remoting Invokers commit

OK, I took a look at the aop clustering.  Very nice!

I think what I'll do is implement a new xaresource interceptor for AOP,
and put it in the transaction module.  It will be a singleton, so all
client side interceptor chains will use the same instance. The
interceptor itself will have a map of Locator to XAResource objects, so
each remote tm will be distinguishable to the transaction manager.  I'm
going to make this into a (client side) mbean because the transaction
manager setup is made up of mbeans and they need to communication
through jmx for lifecycle events. 
Also, for distributed recovery we need to keep track of every remote
jboss instance we have been connected to: we can do this with mbean
persistence. 
I'll use the mbean object name to assure it is a singleton, and the
Locator will still determine the eventual target.

There may be some changes needed in the structure of the
ServerInvocationHandler to make this work really well.

It seems to me that we might be able to gradually ease into "one
interceptor model" by first making the client and server ejb
interceptors use the aop invocation object, then changing them to use
the aop interceptors.  If we had one invocation object, we could use the
aop clustering (and soon, dtm) for ejbs.

david jencks

On 2003.04.24 17:00 Bill Burke wrote:
> 
> 
> > -----Original Message-----
> > From: jbo...@li...
> > [mailto:jbo...@li...]On Behalf Of
> David
> > Jencks
> > Sent: Thursday, April 24, 2003 4:18 PM
> > To: jbo...@li...
> > Subject: RE: [JBoss-dev] Remoting Invokers commit
> >
> >
> > On 2003.04.24 15:26 Bill Burke wrote:
> > > David,
> > >
> > > Thanks for doing this work!  A couple of things:
> > >
> > > I was hoping the configuration would change from providing the
> invoker
> > > mbean, to just providing a connection URI and maybe a Handler 
> > > string.
>  I
> > > was
> > > hoping proxy creation would create a Remoting Client and stuff 
> > > that
> in
> > > the
> > > proxy object.
> >
> > I'm not sure exactly what you mean.  I'll try to explain what 
> > happens
> now
> > and what I'd like to have happen.
> >
> 
> What I mean is, I was hoping that all the proxy factory needed was a 
> URI to build its proxy.
> 
> > When you construct a proxy on the server, and serialize it, it has 
> > the dynamic proxy(s), a bunch of client interceptors, the 
> > InvokerXAResource mbean/invoker, and the RemotingAdapter 
> > mbean/invoker.  If you added
> more
> > mbean/invokers in the chain, they'd get onto the client also.
> >
> 
> What do you mean by these invokers?  Is this a transport specific 
> interceptor chain?  What's the RemotingAdapter mbean/invoker?  Is this

> just the stub that does the communication with the server?  Why do you

> need an mbean for this?  The Remoting framework decides whether or not

> a singleton
> is needed for the stub.  org.jboss.remoting.Client objects are cheap
to
> create, AFAICT.
> 
> > On the client, this all gets deserialized.  The mbean/invokers
> implement
> > readResolve so that if there is already an mbean in the client with 
> > the appropriate object name, that is returned.  If not, the 
> > (internal)readResolve method installs the object as an mbean and
> creates
> > and registers the other mbeans it needs to do its work.  Similarly, 
> > if
> you
> > look up UserTransaction, when it installs itself it also installs 
> > the transaction manager.
> >
> > Therefore, there will be client interceptors for each proxy
> deserialized,
> > but only one invoker chain per target server/transport/(subsystem).
> >
> > I don't want to drag the invoker chain back to the client with every

> > proxy.  I can see at least two possibilities:
> > --preinstall the invoker chains either with a configuration such as
> > *-service.xml or perhaps some jmx based method of copying them from
the
> > server.
> > --have a lookup service for the invoker that creates the invoker
chains
> > when they are missing.
> >
> > Either way, we need  a lookup service to connect the end of the 
> > client invoker chain with the appropriate invoker.  Is this what you

> > were
> getting
> > at?
> > >
> > >
> > > What is this InvokerXAResource stuff?
> >
> > The client side of the dtm.  Remote UserTransactions now appear to 
> > work over Remoting transports.  I want to test more "official" 
> > distributed transactions.  Does anyone have a way to easily set up 2

> > servers and
> run
> > tests on them?
> >
> > The next step I think is to turn the HA stuff into:
> >
> > a client side invoker/"sprayer" that sits in front of a (dynamic) 
> > list
> of
> > (InvokerXAResource) invokers connected to the cluster members.
> >
> 
> Please take a look at how I did the AOP clustering.  It's all URI 
> based. The Cluster interceptor chooses a URI from a list and inserts 
> it into the Invocation object.  The plain old remoting interceptor 
> pulls the URI from the invocation, creates a Client, and invokes.
> 
> I don't see why the InvokerXAResource or the actual transport can't 
> pull the URI from the invocation payload to determine how to 
> communicate.  Am I making any sense?
> 
> Please take a look at the AOP clustering code.  I think it is simple 
> enough to understand and I think it will give you some ideas.
> 
> cluster/src/main/org/jboss/aop/remoting
> aop/src/main/org/jboss/aop/remoting
> 
> 
> 
> > a server side subsystem interceptor that sends back ids/tokens for
> cluster
> > members and interprets exceptions as generic cluster exceptions etc.
> >
> 
> The remoting framework already provides generic exceptions.  The URI 
> Chooser interceptor I talked about above is the interceptor that 
> listens for generic
> Remoting connect exceptions.  So the Chooser looks like this
> 
> PSEUDOCODE
> invoke(Invocation invocation) {
> 
>    while (true) {
>      InvokerLocator locator = loadBalance();
> 
>      invocation.attach("INVOCATION URI", locator);
> 
>      try
>      {
>          invokenext;
>      }
>      catch (GenericConnectException)
>      {
>          continue;  // try again
>      }
> 
> }
> 
> > Currently there are 2 invocation objects involved: the ejb one and 
> > the remoting one.  As a result, the ejb one gets wrapped by a 
> > remoting one. Using the same invocation object for both would allow 
> > applying dt, ha
> and
> > security to any remotable service/subsystem simply by including the 
> > appropriate interceptors at each end.
> >
> 
> This is a bit more work.
> 
> > >
> > > Anyways, I am extremely grateful that you have taken this on.
> > >
> > >
> > > Other comments:
> > >
> > > One of the drawbacks of the Remoting framework is that there must 
> > > be
> a
> > > Handler created for each Connector.  Seems like a better approach
> would
> > > be
> > > to register a handler with a lookup service and have the
> > connector lookup
> > > the handler through that registry.
> >
> > This could be done by making all the handlers mbeans and supplying a
> list
> > of such mbeans to the connector.  But...
> >
> > Although attractive, I don't think this will work, since we want to 
> > support 2 way communication.  Therefore the ServerInvocationHandler 
> > has to know which connector it is attached to in case it needs to 
> > initiate sending messages.
> >
> > thanks
> > david
> >
> > >
> > > Regards,
> > >
> > > Bill
> > >
> > > > -----Original Message-----
> > > > From: jbo...@li...
> > > > [mailto:jbo...@li...]On Behalf 
> > > > Of
> > > David
> > > > Jencks
> > > > Sent: Thursday, April 24, 2003 2:23 PM
> > > > To: jbo...@li...
> > > > Cc: EJB...@ad...
> > > > Subject: [JBoss-dev] (no subject)
> > > >
> > > >
> > > > I've committed a first draft of EJB invocation over the remoting

> > > > framework.
> > > >
> > > > 1. Please let me know of tests this may break or other problems.
> The
> > > > testsuite has enough errors at the moment that this is
> > difficult for me
> > > to
> > > > determine accurately.
> > > >
> > > > 2. Currently this is set up only to use the socket transport 
> > > > layer.
>  I
> > > > expect to add the other transports shortly.  The default invoker

> > > > is now the remoting/socket invoker.
> > > >
> > > > 3. When can I remove the old invokers?  There is some cleanup I
> would
> > > like
> > > > to do but have no particular desire to do on code about to be
> removed.
> > > >
> > > > 4. I modified the remoting Connector to allow dynamic 
> > > > registration
> of
> > > > subsystems and to conform better to the jboss service lifecycle.

> > > > Shouldn't the Connector also allow deregistration of subsystems?
> > > >
> > > > 4. Future work:
> > > >
> > > > --Move use of WorkManager/thread pool into the remoting 
> > > > transport layer and make the remoting server side subsystems 
> > > > into interceptor
> > stacks.  This
> > > > will allow things like plugging in HA and transaction import 
> > > > into
> any
> > > > subsystem.
> > > >
> > > > --Translate HA invoker into appropriate interceptors.
> > > >
> > > > --jndi over remoting framework.
> > > >
> > > > Thanks
> > > > david jencks
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This sf.net email is sponsored by:ThinkGeek
> > > > Welcome to geek heaven.
> > > > http://thinkgeek.com/sf 
> > > > _______________________________________________
> > > > Jboss-development mailing list 
> > > > Jbo...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf 
> > > _______________________________________________
> > > Jboss-development mailing list 
> > > Jbo...@li...
> > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> > >
> > >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf 
> > _______________________________________________
> > Jboss-development mailing list 
> > Jbo...@li...
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf 
> _______________________________________________
> Jboss-development mailing list Jbo...@li...
> https://lists.sourceforge.net/lists/listinfo/jboss-development
> 
> 

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf _______________________________________________
Jboss-development mailing list Jbo...@li...
https://lists.sourceforge.net/lists/listinfo/jboss-development