You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by ha...@apache.org on 2002/04/30 07:21:07 UTC
cvs commit: jakarta-avalon-excalibur/altrmi/src/xdocs transports.xml
hammant 02/04/29 22:21:06
Modified: altrmi/src/xdocs transports.xml
Log:
more wrods on transports
Revision Changes Path
1.4 +111 -36 jakarta-avalon-excalibur/altrmi/src/xdocs/transports.xml
Index: transports.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/altrmi/src/xdocs/transports.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- transports.xml 26 Apr 2002 05:41:16 -0000 1.3
+++ transports.xml 30 Apr 2002 05:21:06 -0000 1.4
@@ -12,40 +12,83 @@
<body>
<s1 title="Introduction">
<p>
- AltRMI has pluggable and reimplementable transports. They differ in terms of speed and layers of transport. Some are in VM, others between VMs using sockets and various Java concepts.
+ AltRMI has pluggable and reimplementable transports. They differ in terms of speed and layers of transport.
+ Some are in VM, others between VMs using sockets and various Java concepts.
</p>
- </s1>
- <s1 title="Transports">
- <p>
- Blah
+ </s1>
+ <s1 title="Supplied Request/Response Transports">
+ <p>
+ The supplied transports fall into two categories - Intra-JVM and Inter-JVM. The Inter-JVM types are for
+ bridging a network divide over TCP/IP. This can also mean two JVMs in the same physical machine, using
+ local-loop TCP/IP. The Intra-JVM types are dor situations where normal dynamic proxy will not work. For
+ example when the client and the server both have a definition of the same interfact in different
+ classloaders. Most Java projects do not involve trees of classloaders, but writing frameworks like
+ Avalon-Phoenix or or an implementation of the EJB specification will.
+ </p>
+ <p>
+ All of these transports are synchronous too. That means that an invokation acorss there connection
+ will wait until the it is completed server side before the next invocation is allowed through.
</p>
- <s2 title="Plain Sockets / ObjectStream & CustomStream varients">
+
+ <s2 title="Plain Sockets / ObjectStream & CustomStream varients">
+ <p>
+ This transport is a streaming type that uses serialization of objects over a TCP/IP connection. There
+ are two variations. The first uses java.io.ObjectInputStream & java.io.ObjectOutputStream (AKA
+ 'ObjectStream', the second uses what we call 'CustomStream'. CustomStream came into being because of this
+ bug <link href="http://developer.java.sun.com/developer/bugParade/bugs/4499841.html">
+ http://developer.java.sun.com/developer/bugParade/bugs/4499841.html</link>
+ which seriously restricts the usefulness of ObjectStream as a transport
+ (and the same java.io classes for other uses). Custom Stream is slower by 20%, but we recommend it's use
+ over ObjectStream. At least until the bug at Sun is fixed (please vote for it).
+ </p>
+ </s2>
+ <s2 title="Over RMI">
<p>
- Blah
+ This is another transport that bridges two different JVMs using TCP/IP. It is actually the fstest of all the
+ TCP/IP using transports. and takes advantage of RMI as it's transport while hiding RMI from the AltRMI
+ client and server.
</p>
</s2>
- <s2 title="Over RMI">
+ <s2 title="Piped with same VM / ObjectStream & CustomStream varients">
<p>
- Blah
- </p>
+ In a similar way to the ObjectStream and CustomStream implementations of the plain sockets transport, these
+ offer trasport using a pipe inside the JVM. Not needed for most users of AltRMI these prove useful for
+ developers making complex trees of classloaders with high separation from each other. As a Pipe is being
+ used there is is some opportunity for buffering of invokations. This might slow the throughput down but
+ this may releieve other parts of a particular design.
+ </p>
</s2>
- <s2 title="Piped with same VM / ObjectStream & CustomStream varients">
+ <s2 title="Direct within same VM">
<p>
- Blah
- </p>
+ There are 'Direct' and 'DirectMarshalled' transports. These are use useful in the same scenarios as
+ the Piped one, but with some small differences. Principally, there is no pipe - the invokation is
+ immediately handled on the server side. With Direct there is also the fact that all mutually visible
+ classes and interfaces woould have to be in a commonly visible classloader. With DirectMarshalled,
+ there can be duplicate interfaces and class definitions as in the streamed types of transport.
+ </p>
</s2>
- <s2 title="Direct within same VM">
+ <s2 title="JNDI">
<p>
- Blah
- </p>
- </s2>
+ Many of the basic transport types are accessible client side through JNDI. This makes the client side usage
+ more standards compliant, but these is no need to choose it over the bespoke AltRMI client usage at all.
+ </p>
+ </s2>
</s1>
- <s1 title="JNDI">
+ <s1 title="Supplied Callback capable Transports">
+ <p>
+ All of these transports are asynchronous. Thais means that an invokation across there connection
+ will does not wait until the reply is ready before it allows another request though. This allows
+ two thing - excpetionally lengthy requests (that might ordinarily affect timeouts) to be performed and
+ callbacks (server invoking requests on the client). There is a smal (15%) cost to using this transport for
+ simple cases, but its benefits outweigh its deficiences.
+ </p>
<p>
- Blah
- </p>
+ Whilst the Callback enabled transports are better from the point of view of asynchronous behaviour
+ </p>
+ <s2 title="xxx">
+ </s2>
</s1>
- <s1 title="Future Transports">
+ <s1 title="Future Transports">
<p>
<ul>
<li>SOAP - Might require additional undynamic "toWSDL()" step.</li>
@@ -58,13 +101,12 @@
<li>Over HTTP (custom impl)</li>
<li>TLS enabled versions of many of the above.</li>
</ul>
- </p>
+ </p>
</s1>
- <s1 title="Speed">
+ <s1 title="Speed">
<p>
Counting the number of 'void testSpeed()' invocations in 10 seconds,
- we can guage the differences (my Athlon900 machine)
-
+ we can guage the differences (Paul's Athlon900/Win2K machine)
</p>
<s2 title="AltRMI types over TCP/IP">
@@ -78,13 +120,13 @@
c) CustomStream over sockets 6069 2.25<br/>
d) ObjectStream over sockets #1 10088 3.73<br/>
- </p>
+ </p>
</s2>
<s2 title="AltRMI types in the same VM">
<p>
- These are useful for complete classloader separation of interface & impl using
- different classloaders. Impl and 'remote' proxy do not need to see the same
+ These are useful for complete classloader separation of interface & impl using
+ different classloaders. Impl and 'remote' proxy do not need to see the same
interfaces etc..<br/>
<br/>
Speed Test type Count Relative<br/>
@@ -92,11 +134,11 @@
e) ObjectStream over Pipe #2 12095 4.48<br/>
f) Direct Marshalled #3 20759 7.68<br/>
g) ObjectStream over Pipe #1 61166 22.64<br/>
- h) Direct Unmarshalled # 2391498 885.08<br/>
-
+ h) Direct Unmarshalled #4 2391498 885.08<br/>
+
#1 Without calling reset() as workaround to the ObjectStream bug
#2 With calling reset() as workaround to the ObjectStream bug
- #3 Completely separates classloaders of client and server. Requires
+ #3 Completely separates classloaders of client and server. Requires
a thread for each though.
#4 Good as DynamicProxy for separation. Does not separate classloaders
of client and server.
@@ -107,25 +149,58 @@
- In VM, without using AltRMI - for comparison.
- The inteface, impl and proxy cannot be separated in terms of
- branches of classloader for these three. The same interfaces
+ branches of classloader for these three. The same interfaces
etc must be visible to both impl and proxy.
<br/>
Speed Test type Count Relative<br/>
- ------------------------------- ------- --------<br/>
+ ------------------------------- ------- --------<br/>
i) DyanmicProxy #5<br/>
(copied from Excalibur) 20282070 7506.32<br/>
j) Hand-coded proxy #5 41214422 15253.30<br/>
k) No Proxy #5 42384804 15686.46<br/>
<br/>
#4 - For all of these three, the actual timing may slow down the test.<br/>
- </p>
+ </p>
</s2>
- </s1>
+ </s1>
+ <s1 title="Secrets of classloading">
+ <p>
+ There is a feature of classloading that affects the way that the an AltRMI using client and server interoperte
+ when it comes to resolving classes and interfaces for a given object. As is widely known, the JVM resolves
+ depended on classes for a being-instantiated object at runtime. The issue concerns a class definition existing
+ twice in a tree of classloaders and whther the JVM considers an instance of each to be of the same type.
+ </p>
+ <p>
+ Consider a tree of three classloaders - A, B and C. Consider that A is the parent classloader of B & C.
+ This means that B can access all the classes mounted by itself and by A. Similarly C can access all the
+ classes mounted by itself and A. Now if A had a singleton that stored a single object via
+ <strong>void setObject(object o);</strong> and <strong>Object getObject();</strong>, and clases in
+ B amp; C could invoke those methods freely, the you might consider that B has a way of taking to C. if B
+ called (essentially) <strong>A.setObject("Hello")</strong>, then C could indeed call <strong>String
+ s = A.getObject()</strong> without ny problem. Say a class being passed were called 'Thing' and was in the
+ classloader of B and duplicated in the classloader of C, but not in A at all, then it would not be passable
+ by the setter/getter mechanism outlined above. Why? The JVM considers then differnt classes because they
+ are mounted in different classloaders (even though from the same source). That is a secret
+ of classloading (at least as it pertains to RPC in one VM).
+ </p>
+ <p>
+ The issue is relevent to AltRMI mostly if it is being used to connect two nodes of a single classloader tree.
+ If the trasport chosen is 'Direct' then you will get ClassCastExceptions thrown by the JVM if you had been
+ passed an Object you wanted to cast up to something, and that something were represented by a class definition
+ in both the server and client nodes of the classloader tree. If the something class were in a mutualy
+ visible parent class loader then no issue would be apparent. IF the client and server were in seperate VMs,
+ then no issue would be apparent, princiapally because on the marchalling to serialized form natly hides the
+ two class definitions from the JVM. This is the clue to the solving of the issue for a particular
+ client/server (in one JVM) confiuration you may be cooking up. If you choose Piped or DirectMarshalled as
+ trasnports, then you can have the same class definition in multiple classloader nodes. Of couse, both Piped
+ and DirectMarshalled are slower than Direct as transports. Configuration choices for the developer/deployer.
+ </p>
+ </s1>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.3 $ $Date: 2002/04/26 05:41:16 $
+ $Revision: 1.4 $ $Date: 2002/04/30 05:21:06 $
</legal>
</footer>
</document>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>