avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject [AltRMI] Changes / a Future
Date Sun, 25 Aug 2002 11:55:46 GMT

Firstly -> 
-> Way cool!!  I missed it happening, but it looks good.

I'd like to start a dialogue with persons intersted in pushing AltRMI 
forward.  Namely those are Leif, Peter Royal, Vinay and Jeff looking at 
the CVS logs.   Stephen too is interested given some previous Merlin 
work. There are also some users of AltRMI in companies for bespoke 

*Async behaviour*

Joe Walnes (Mr Sitemesh - blog : http://radio.weblogs.com/0108103/), 
Charles Lowell (Thoughtworks) and myself are slowing pushing towards an 
Asynchronous aspect to AltRMI. Basically if a methods returns void and 
throws no exceptions, it could be executed asynchonously.  This is a 
publication choice of course.  Joe talks of a default implementation of 
'over AltRMI' but envisages ones over JMS and other specialised 
messaging transports, possibly including the way-cool JavaGroups.  With 
a JMS tyle solution hierarchies of messaging factories could be laced 
together to releive the burdon on the server and guaranteed deliver 
could be a value added possibility.

*Unit Tests*

I've added some more, based on an orginal one from Charles and Joe.  We 
can now unit test, well integration test, all of the transports that 
AltRMI offers.  There are more to add to specifically test the various 
tylpes of class loader and authentication, but they will be added later. 
 There is work needed to make the Piped tests perform better - there 
must be some thrashing due to lack of threads in the test cases 
presently.  I say that because the piped speeds suck, which is not my 
actual experience. It would also be nice to extract the testSpeed() 
elapsed time from the Jinit XML and make a page for use on the website 
with actual relative speeds.  Has anyone got Zen level XSL and can take 
on the task?

*Jar Files*

Currently there are five jars files for AltRMI.  Given that there are 
multiple transport implementations, it is likely that users will use jar 
files that contain transports that are just not needed.  Should we push 
towards more jars files?  There is also a case that we should push 
towards less jar files bu combining the server and client interfaces 
ones into the common.  Thoughts?

*Dual level client side proxies*

Consider an interface 'HowdieInterface' that has a single method 'void 
howdie()'.  AltRMI generates the equiv of:

  public class AltrmiGeneratedHowdie_Main implements 
    private transient org.apache.excalibur.altrmi.client.ProxyHelper 
    public AltrmiGeneratedHowdie_Main 
(org.apache.excalibur.altrmi.client.ProxyHelper proxyHelper) {
        mProxyHelper = proxyHelper;
    public void howdie () {
        // method body
  public final class AltrmiGenerated2Howdie_Main extends 
AltrmiGeneratedHowdie_Main implements HowdieInterface {
    public AltrmiGenerated2Howdie_Main 
(org.apache.excalibur.altrmi.client.ProxyHelper proxyHelper) {

This is done so that in theory a remote client like BeanShell (I love 
it), can use the service and do preper reflection over the methods 
without dealing with an java.reflect.Proxy style invocation handler 
which is a bit of a black-box to reflection tools.  Anyway a couple of 
people have requested that the classloader should get dependencies over 
AltRMI like RMI does.  Specifically that would mean HowdieInterface in 
the above example.  At the same time we could combine the two above 
classes into a single class.  This would be quite easy for the Javac 
using proxy generator.  For the BCEL one ot would be harder for me cos I 
have trouble understanding it to the level Vinay does.  Thoughts?


Anyone want to take this on?  Reusing Apache-Axis or James Strachan's 
Jelly (jakarta-commons-sandbox/jelly) or something else?

*Custom XML transport*

I'd though for a while that something that leverages 
http://www.csse.monash.edu.au/~bren/JSX/tech.html would be really cool. 
 Unfortunately it is dual GPL/Commercial license which completely 
precludes any effort on our part to ship anything that includes it.  We 
could. I'm sure do some work that codes against it using some 
Class.forName(..) way of circumventing the licnse issue, but previously 
it was incompatible with JDK 1.4.  It would be interesting to see the 
speed of a JSX using transport over one that utilises the JDK serialzed 
objects (all other AltRMI transports).  It would also be interesting to 
see how version tolerant this would be (XMLs promise).

I'm beginning to think that James Strachan's Jelly is the way forward 
though. Talking to James there is some realy interesting work going on 
there.  It is ahead of a curve presently and bit of a tool looking for 
its killer app. (Blog of James http://radio.weblogs.com/0112098/ change 
the skin dude!).

*More transportable pass-by-value types*

Currently the primatives and basic dervarions of plain Object are 
supported provided they are transportable.  We can also do derivations 
of Object[] but I think more complex things require more work. Is 
Object[][] ever going to need to be supported?  Also I feel that some 
special work needs to be done for Collection and Iterator etc.  Thoughts?

*Distributed Garbage Collection*

We have implemented this so far using WeakReferences on both the client 
and server side.  .Net uses leasing.  The weak references is a perfect 
world scenario, but if a client dies without tidying up, then the server 
will be prevented from garbage collecting an item on teh server side. 
 It also relies on the fact that Java does actuall GC objects when they 
are inaccessible, and not when there are tight memory situations. 
 Should we also implement a leasing scheme?  My view is that it would 
supplement the weak reference impl addressing the client-death scenario. 

*AltRMI tunnelling*

Just an idea.  Is there a concept of a firewall or proxy server for 
AltRMI?  I.e. a way of tunnelling an AltRMI connection through a server. 
 Some listener that does nothing other than forward calls to some other 
thing.  Thoughts?

*AltRMI redirection*

Another on the original todo list.  Client esablished a dialog with a 
server but is redicrected to another server which unknown to the user of 
lookup(..).  A poor man's load balancing. Thoughts?

*Seperation of Content and Addressing*

Currently some bastardized command pattern is uses as the messaging 
protocol (over the transport) for method invocations.  The whole thing 
has to be deserialzed to show what type of command it is.   If this were 
split into basic info and a methods args components, then tunnelling 
might be easier.  Deterministic routing might be easier too.  Having 
said that basic client to server connections would be slower.

*Any Other Business*

Anything else to discuss?


- Paul

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message