Excalibur AltRMI / Tests

Delivered-To: mailing list avalon-cvs@jakarta.apache.org Received: (qmail 14435 invoked by alias); 1 May 2002 18:44:26 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Date: 1 May 2002 18:44:17 -0000 Message-ID: <20020501184417.17534.qmail@icarus.apache.org> From: hammant@apache.org To: jakarta-avalon-site-cvs@apache.org Subject: cvs commit: jakarta-avalon-site/docs/excalibur/altrmi tests.html client-usage.html connection-listeners.html facades.html generating-proxies.html index.html otherfeatures.html pingers.html publishing.html transports.html X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N hammant 02/05/01 11:44:17 Modified: docs/excalibur/altrmi client-usage.html connection-listeners.html facades.html generating-proxies.html index.html otherfeatures.html pingers.html publishing.html transports.html Added: docs/excalibur/altrmi tests.html Log: more words for altrmi Revision Changes Path 1.2 +4 -1 jakarta-avalon-site/docs/excalibur/altrmi/client-usage.html Index: client-usage.html =================================================================== RCS file: /home/cvs/jakarta-avalon-site/docs/excalibur/altrmi/client-usage.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- client-usage.html 5 Apr 2002 15:11:45 -0000 1.1 +++ client-usage.html 1 May 2002 18:44:17 -0000 1.2 @@ -41,7 +41,7 @@ Download

-API Docs +API Docs

Other Features @@ -74,6 +74,9 @@

Connection Listeners +

+Tests

1.2 +4 -1 jakarta-avalon-site/docs/excalibur/altrmi/connection-listeners.html Index: connection-listeners.html =================================================================== RCS file: /home/cvs/jakarta-avalon-site/docs/excalibur/altrmi/connection-listeners.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- connection-listeners.html 5 Apr 2002 15:11:45 -0000 1.1 +++ connection-listeners.html 1 May 2002 18:44:17 -0000 1.2 @@ -41,7 +41,7 @@ Download

-API Docs +API Docs

Other Features @@ -74,6 +74,9 @@

Connection Listeners +

+Tests

1.2 +4 -1 jakarta-avalon-site/docs/excalibur/altrmi/facades.html Index: facades.html =================================================================== RCS file: /home/cvs/jakarta-avalon-site/docs/excalibur/altrmi/facades.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- facades.html 5 Apr 2002 15:11:45 -0000 1.1 +++ facades.html 1 May 2002 18:44:17 -0000 1.2 @@ -41,7 +41,7 @@ Download

-API Docs +API Docs

Other Features @@ -74,6 +74,9 @@

Connection Listeners +

+Tests

1.2 +4 -1 jakarta-avalon-site/docs/excalibur/altrmi/generating-proxies.html Index: generating-proxies.html =================================================================== RCS file: /home/cvs/jakarta-avalon-site/docs/excalibur/altrmi/generating-proxies.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- generating-proxies.html 5 Apr 2002 15:11:45 -0000 1.1 +++ generating-proxies.html 1 May 2002 18:44:17 -0000 1.2 @@ -41,7 +41,7 @@ Download

-API Docs +API Docs

Other Features @@ -74,6 +74,9 @@

Connection Listeners +

+Tests

1.3 +3 -0 jakarta-avalon-site/docs/excalibur/altrmi/index.html Index: index.html =================================================================== RCS file: /home/cvs/jakarta-avalon-site/docs/excalibur/altrmi/index.html,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- index.html 7 Apr 2002 10:22:38 -0000 1.2 +++ index.html 1 May 2002 18:44:17 -0000 1.3 @@ -75,6 +75,9 @@

Connection Listeners

+Tests +

1.2 +4 -1 jakarta-avalon-site/docs/excalibur/altrmi/otherfeatures.html Index: otherfeatures.html =================================================================== RCS file: /home/cvs/jakarta-avalon-site/docs/excalibur/altrmi/otherfeatures.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- otherfeatures.html 5 Apr 2002 15:11:45 -0000 1.1 +++ otherfeatures.html 1 May 2002 18:44:17 -0000 1.2 @@ -41,7 +41,7 @@ Download

-API Docs +API Docs

Other Features @@ -74,6 +74,9 @@

Connection Listeners +

+Tests

1.2 +27 -4 jakarta-avalon-site/docs/excalibur/altrmi/pingers.html Index: pingers.html =================================================================== RCS file: /home/cvs/jakarta-avalon-site/docs/excalibur/altrmi/pingers.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- pingers.html 5 Apr 2002 15:11:45 -0000 1.1 +++ pingers.html 1 May 2002 18:44:17 -0000 1.2 @@ -41,7 +41,7 @@ Download

-API Docs +API Docs

Other Features @@ -75,6 +75,9 @@

Connection Listeners

+Tests +

@@ -110,8 +113,7 @@

Although it may not be necessary for all types of transport, there is a mechanism called a pinger that can be used to keep alive - the connection. It is possible to write your own or extend the exiting - ones if there are different requirements. Pingers run on the client side. + the connection. Pingers run on the client side.

@@ -122,11 +124,32 @@

- + + +

Pinger types	Pinger Interface
+ + + It is possible to write your own or extend the exiting + ones if there are different requirements. The interface for bespoke pingers + is here + + + +

+
+

+ + + + + + @@ -119,16 +123,27 @@

Pinger types

Here are the types of pinger implemented so far 1.2 +4 -1 jakarta-avalon-site/docs/excalibur/altrmi/publishing.html Index: publishing.html =================================================================== RCS file: /home/cvs/jakarta-avalon-site/docs/excalibur/altrmi/publishing.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- publishing.html 5 Apr 2002 15:11:45 -0000 1.1 +++ publishing.html 1 May 2002 18:44:17 -0000 1.2 @@ -41,7 +41,7 @@ Download

-API Docs +API Docs

Other Features @@ -74,6 +74,9 @@

Connection Listeners +

+Tests

1.2 +171 -49 jakarta-avalon-site/docs/excalibur/altrmi/transports.html Index: transports.html =================================================================== RCS file: /home/cvs/jakarta-avalon-site/docs/excalibur/altrmi/transports.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- transports.html 5 Apr 2002 15:11:45 -0000 1.1 +++ transports.html 1 May 2002 18:44:17 -0000 1.2 @@ -41,7 +41,7 @@ Download

-API Docs +API Docs

Other Features @@ -75,6 +75,9 @@

Connection Listeners

+Tests +

@@ -108,7 +111,8 @@

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

- + + +

Transports

Supplied Request/Response Transports

- Blah +

+ 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.

+ 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. +

+ +

@@ -136,10 +151,17 @@ @@ -155,11 +177,13 @@ @@ -174,11 +198,15 @@ @@ -193,17 +221,82 @@ + +

-
+

- Blah + 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 + http://developer.java.sun.com/developer/bugParade/bugs/4499841.html + 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).

-
+

- 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. +

-
+

- Blah -

+ 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. +

-
+

- Blah -

+ 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. +

+ +

+
+ +

+ + + + + + + +

JNDI

+
+ +

+ 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. +

+ +

+
+ +

+
+

+ + + + + + @@ -217,7 +310,7 @@ - -

Supplied Callback capable Transports

+
+ +

+ 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. +

+ +

+ Whilst the Callback enabled transports are better from the point of view of asynchronous behaviour +

+ +

+ + + + + +

xxx

-
+

@@ -243,25 +336,7 @@ -

- -

-
-

- - - - - - @@ -275,12 +350,11 @@ @@ -324,8 +398,8 @@

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

@@ -334,11 +408,11 @@ e) ObjectStream over Pipe #2 12095 4.48

f) Direct Marshalled #3 20759 7.68

g) ObjectStream over Pipe #1 61166 22.64

- h) Direct Unmarshalled # 2391498 885.08

- + h) Direct Unmarshalled #4 2391498 885.08

+ #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. @@ -363,11 +437,11 @@ - 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.

Speed Test type Count Relative

- ------------------------------- ------- --------

+ ------------------------------- ------- --------

i) DyanmicProxy #5

(copied from Excalibur) 20282070 7506.32

j) Hand-coded proxy #5 41214422 15253.30

@@ -376,13 +450,61 @@

#4 - For all of these three, the actual timing may slow down the test.

JNDI

-
- -

- Blah -

-
+

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)

@@ -305,7 +379,7 @@ d) ObjectStream over sockets #1 10088 3.73

+ + + + + +
+

+ + + + + + 1.1 jakarta-avalon-site/docs/excalibur/altrmi/tests.html Index: tests.html =================================================================== Excalibur AltRMI / Tests

Secrets of classloading

+
+ +

+ 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. +

+ +

+ 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 + void setObject(object o); and Object getObject();, 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) A.setObject("Hello"), then C could indeed call String + s = A.getObject() 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). +

+ +

+ 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. +

Back to Avalon

Back to Excalibur

About

Using

Excalibur AltRMI / Tests

Excalibur AltRMI / Tests

by Paul Hammant

Introduction

There are a number of examples that come with AltRMI. They are only present in the source download or the CVS depot, so we will assume that you have one or the other of these.

Tests using AltRMI

The tests all run under Ant control. Some tests are client and server, others are in a single VM. You may need two command shells for the client/server tests.

The majority of the tests transfer a primary interface, TestInterface, between server and client. It has a number of methods that test the passing of primatives and objects as parameters and return types. Apart from this testing of features, the speed of the transport type is tested. This is simply the counting of as many repetetive invocations of the same method in ten seconds as possible. It is used for an statistically incorrect comparison of transports.

ObjectStream Over Plain Sockets

The ObjectStream over plain sockets tests are launched from a build file called socketa.xml. You need two command shells. In the first launch ant -buildfile socketa.xml server, and in the second ant -buildfile socketa.xml client

CustomStream Over Plain Sockets

The CustomStream over plain sockets tests are launched from a build file called socketb.xml. You need two command shells. In the first launch ant -buildfile socketb.xml server, and in the second ant -buildfile socketb.xml client

CustomStream Over Plain Sockets, using callback handlers

The CustomStream over plain sockets tests are launched from a build file called socketc.xml. You need two command shells. In the first launch ant -buildfile socketc.xml server, and in the second ant -buildfile socketc.xml client. The callback capable layer is not used to its fullest capacity, in that no callbacks ae setup. This is most useful for a comparative speed test.

RMI

The RMI tests are launched from a build file called rmi.xml. You need two command shells. In the first launch ant -buildfile rmi.xml server, and in the second ant -buildfile rmi.xml client.

Piped

The Piped tests are launched from a build file called piped.xml. You need a single shell. To test the piped transport with generated proxies already in the client's classloader, launch ant -buildfile piped.xml clientclasses. To test the piped transport with generated proxies retrieved from the server by the client, launch ant -buildfile piped.xml serverclasses. To test the piped transport with generated proxies generated on demand by the server for the client, launch ant -buildfile piped.xml dynamicclasses.

Direct

The Direct tests are launched from a build file called direct.xml. You need a single shell. To test the direct connection of client and server launch ant -buildfile direct.xml direct. To test the direct connection of client and server with marshalling of communications launch ant -buildfile direct.xml direct-marshalled.

Tests not using AltRMI

These tests are used for a speed comparison of native Java techniques. This type of testing is possible because AltRMI uses normal Java interfaces. All are run from the proxies.xml Ant script in a single command shell.

Dynamic Proxy

This test uses dynamically generated proxies, which are normally used when you want to do implemetation hiding. To test, launch ant -buildfile proxies.xml dynamic-proxy.

Coded Proxy

This test uses human crafted proxy. To test, launch ant -buildfile proxies.xml coded-proxy.

Non Proxy

This test directly wires the server to the clint via TestInterface. To test, launch ant -buildfile proxies.xml un-proxy. This, of course, is the fastest possible connection of client and server.

-- To unsubscribe, e-mail: For additional commands, e-mail: