avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hamm...@apache.org
Subject cvs commit: jakarta-avalon-excalibur/altrmi/src/xdocs transports.xml
Date Tue, 30 Apr 2002 05:21:07 GMT
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 &amp; CustomStream varients"> 
          
  +
  +      <s2 title="Plain Sockets / ObjectStream &amp; 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 &amp; 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 &amp; 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 &amp; 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 &amp; impl using

  -	    different classloaders. Impl and 'remote' proxy do not need to see the same 
  +	    These are useful for complete classloader separation of interface &amp; 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 &amp; 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:   <mailto:avalon-cvs-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-cvs-help@jakarta.apache.org>


Mime
View raw message