harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zakharov, Vasily M" <vasily.m.zakha...@intel.com>
Subject RE: [rmi] package comparison (was Re: Contribution of RMI framework)
Date Thu, 20 Apr 2006 13:54:41 GMT
Daniel,

> We started our development as a clean room implementation
> of the package following the spec; and we found it -the spec
> (JRMP included)- to be vague and incomplete making it impossible
> for us to get interoperability without doing "code inspection"
> or "reverse engineering", which was not allowed by the imposed
> clean-room restriction. I believe you faced the same situation,
> and it will be good to know how you tackle it without compromising
> your development.

Of course, we also followed the clean-room restrictions, but we
struggled to be compatible with reference implementation and used
a lot of black-box testing to find out what goes on in the reference
implementation data exchange.

> Having said that, I believe comparision between packages should
> be done based on functionality and NOT on interoperability since
> it is -at least- underspecified and it can be acomplished with further
> wire protocol information.

Regretfully, I can't agree with this approach. Our target is providing
the end users out there with a free open source Java implementation
they can really use in their applications. And users generally don't
care about quality of specifications - what they need is the tool
they can take and use, and that will work and satisfy their needs.
That's why I think it's very important to not let the poor quality
of the specification stop us from giving the community an effective
and compatible implementation.

> Needeless to say, I'm aware of the critical impact interoperability
> has and we are currently working on that.

By the way, one of the very important interoperability issues is the
1.1 protocol version. It's really obsolete, and there's a great
temptation
to give up on implementing it, but the reference implementation strictly
adhers to 1.1 protocol in Distributed Garbage Collection, so we must
have 1.1 protocol operational in order to be practically compatible with
reference implementation.

Vasily Zakharov
Intel Middleware Products Division


-----Original Message-----
From: Daniel Gandara [mailto:danielgandara@neosur.com] 
Sent: Thursday, April 20, 2006 1:17 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [rmi] package comparison (was Re: Contribution of RMI
framework)

Vasily,

    You are not missing anything, our package does not allow
interoperability simply because you cannot derive it from the
spec.  We started our development as a clean room implementation
of the package following the spec; and we found it -the spec (JRMP
included)- to be vague and incomplete making it impossible for us to
get interoperability without doing "code inspection" or "reverse
engineering", which was not allowed by the imposed clean-room
restriction.   I believe you faced the same situation, and it will be
good to know how you tackle it without compromising your development.
    Our strategic decision at that moment was to move forward on the
development being sure about the "cleanliness" and left the reverse
engineering of the wire protocol to be done later after the package
is complete.  This is the main reasons why I sent the "[rmi] spec
issues"
post presenting the problems we found on the spec; which I believe are
strong enough to ask for a JSR or at least a clarification on the spec.
For a detailed list of the issues we found on the spec please go to
http://www.itc.unc.edu.ar/javadev/rmi/specissues.html .
    Having said that, I believe comparision between packages should
be done based on functionality and NOT on interoperability since it
is -at least- underspecified and it can be acomplished with further wire
protocol information.   Needeless to say, I'm aware of the critical
impact
 interoperability has and we are currently working on that.

Daniel

PS: if you do have further information/description of the JRMP protocol
please send it ot me, since it will be very usefull.


----- Original Message ----- 
From: "Zakharov, Vasily M" <vasily.m.zakharov@intel.com>
To: <harmony-dev@incubator.apache.org>
Sent: Tuesday, April 18, 2006 2:57 PM
Subject: RE: [rmi] package comparison (was Re: Contribution of RMI 
framework)


Daniel,

I've been trying to do some comparisons, as I promised, and I believe
I'm missing something.

I was testing the interoperability, and when I tried to use an "Intel"
RMI client against an "ITC" server, it failed, although it worked
against a "Sun" server. Changing client and server produces the same
result. Here're the stack traces I get, the test code and the config.
Any idea, what I'm
doing wrong?

Vasily Zakharov
Intel Middleware Products Division


Stack trace 1 ("ITC" client, "Sun" or "Intel" server):

java.rmi.ConnectIOException: I/O exception Creating Connection; nested
exception is:
        java.rmi.MarshalException: Exception marshaling JRMP Header;
nested exception is:
        java.rmi.UnmarshalException: Exception reading the Header
response; nested exception is:
        java.io.EOFException
        at
ar.org.fitc.rmi.transport.ConnectionPool.getClientConnection(Unknown
Source)
        at ar.org.fitc.rmi.transport.TransportManager.invoke(Unknown
Source)
        at ar.org.fitc.rmi.server.UnicastRemoteRefImpl.invoke(Unknown
Source)
        at ar.org.fitc.rmi.registry.RegistryImpl_Stub.lookup(Unknown
Source)
        at Client.main(Client.java:14)
Caused by: java.rmi.MarshalException: Exception marshaling JRMP Header;
nested exception is:
        java.rmi.UnmarshalException: Exception reading the Header
response; nested exception is:
        java.io.EOFException
        at
ar.org.fitc.rmi.transport.StreamClientConnection.handshake(Unknown
Source)
        at
ar.org.fitc.rmi.transport.StreamClientConnection.establishConnection(Unk
nown Source)
        ... 5 more
Caused by: java.rmi.UnmarshalException: Exception reading the Header
response; nested exception is:
        java.io.EOFException
        at
ar.org.fitc.rmi.transport.jrmp.ClientProtocolHandler.readHandshakeRespon
se(Unknown Source)
        ... 7 more
Caused by: java.io.EOFException
        at java.io.DataInputStream.readByte(Unknown Source)
        ... 8 more


Stack trace 2 ("Intel" client, "ITC" server):

java.rmi.ConnectIOException: Unable to acknowledge protocol with server;
nested exception is:
        java.io.EOFException
        at
org.apache.harmony.rmi.transport.tcp.TcpConnection.serverProtocolAck(Tcp
Connection.java:145)
        at
org.apache.harmony.rmi.client.ClientConnection.<init>(ClientConnection.j
ava:90)
        at
org.apache.harmony.rmi.transport.tcp.TcpConnection.<init>(TcpConnection.
java:73)
        at
org.apache.harmony.rmi.client.ClientConnectionManager.getConnection(Clie
ntConnectionManager.java:107)
        at
org.apache.harmony.rmi.remoteref.UnicastRef.newCall(UnicastRef.java:226)
        at
org.apache.harmony.rmi.remoteref.UnicastRef.invoke(UnicastRef.java:127)
        at
org.apache.harmony.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_St
ub.java:134)
        at Client.main(Client.java:14)
Caused by: java.io.EOFException
        at java.io.DataInputStream.readByte(Unknown Source)
        at
org.apache.harmony.rmi.transport.tcp.TcpConnection.serverProtocolAck(Tcp
Connection.java:112)
        ... 7 more


Server.java:

import java.rmi.Remote;
import java.rmi.RemoteException;
import java.rmi.RMISecurityManager;
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;
import java.rmi.server.UnicastRemoteObject;

interface TestRemoteInterface extends Remote {
    public String test() throws RemoteException;
}

class TestRemoteObject implements TestRemoteInterface {
    public String test() throws RemoteException {
        System.out.println("TestRemoteObject.test() run");
        return "SUCCESS";
    }
}

public class Server {
    public static void main(String[] args) {
        TestRemoteObject obj = null;

        try {
            System.out.println("Setting security manager");
                System.setSecurityManager(new RMISecurityManager());
            System.err.println("Creating registry");
                Registry registry = LocateRegistry.createRegistry(1099);
            System.out.println("Creating remote object");
                obj = new TestRemoteObject();
            System.out.println("Exporting remote object");
                UnicastRemoteObject.exportObject(obj, 5555);
            System.out.println("Binding object to registry");
                registry.rebind("TestRemoteObject", obj);
            System.out.println("Sleeping 10 seconds");
                Thread.sleep(10000);
        } catch (Throwable e) {
            e.printStackTrace();
            System.err.println("ERROR");
        } finally {
            if (obj != null) {
                System.out.println("Unexporting remote object");

                try {
                    if (UnicastRemoteObject.unexportObject(obj, false))
{
                        System.out.println("Unexport FALSE");
                    } else {
                        if (UnicastRemoteObject.unexportObject(obj,
true)) {
                            System.out.println("Unexport TRUE");
                        } else {
                            System.out.println("Unexport FAILED");
                            System.err.println("ERROR");
                            System.exit(-1);
                        }
                    }
                } catch (Throwable e) {
                    e.printStackTrace();
                    System.err.println("ERROR");
                    System.exit(-1);
                }
            }
        }
    }
}


Client.java:

import java.rmi.RMISecurityManager;
import java.rmi.registry.Registry;
import java.rmi.registry.LocateRegistry;

public class Client {
    public static void main(String[] args) {
        try {
            System.out.println("Setting security manager");
                System.setSecurityManager(new RMISecurityManager());
            System.err.println("Locating registry");
                Registry registry = LocateRegistry.getRegistry();
            System.err.println("Looking for object");
                TestRemoteInterface obj = (TestRemoteInterface)
                        registry.lookup("TestRemoteObject");
            System.err.println("Object found: " + obj);
                System.err.println("Calling method");
            Object ret = obj.test();
                System.err.println("Object returned: " + ret);
            System.err.println("SUCCESS");
        } catch (Throwable e) {
            e.printStackTrace();
            System.err.println("FAIL");
        }
    }
}


all.policy:

grant{
    permission java.security.AllPermission;
};


-----Original Message-----
From: Daniel Gandara [mailto:danielgandara@neosur.com]
Sent: Monday, April 17, 2006 7:38 PM
To: harmony-dev@incubator.apache.org
Subject: [rmi] package comparison (was Re: Contribution of RMI
framework)

Vasily,
    a couple of things about package comparison:

a) java 5.0 vs 1.4.2
 Our rmi package was developed according to 5.0 rmi spec, and
it takes full advantage of 5.0 new features (like java.util.concurrent)
 Since Harmony classlib and VMs are still in 1.4.2 we deployed
a 1.4.2 version of our package in which we removed the 5.0
dependencies.    There is obviously a performance penalty
paid by the 1.4.2 release of the package.
You can find both versions of the packages at
http://issues.apache.org/jira/browse/HARMONY-211

b) compatibility with reference implementation
   within our contribution you will find a complete set of test cases
(source code and documentation for each).   We run these test cases
against our package before contributing it, so I guess one way to
move further is to cross run test cases (you run ours and we run
yours).   What do you think?

c) performance analysis and comparison
    I believe the first step here is to get along about which is the
workload or set of applications that represent a "real" use of rmi
package.   I see a big challenge here...

I'll wait for your comments,

Daniel

----- Original Message ----- 
From: "Zakharov, Vasily M" <vasily.m.zakharov@intel.com>
To: <harmony-dev@incubator.apache.org>
Sent: Friday, April 14, 2006 1:17 PM
Subject: RE: Contribution of RMI framework


Hi, Mikhail,

Regretfully, the method-to-method comparison would hardly be effective
with RMI, as it's a highly integrated component.

80% of implementation is hidden in non-public API, and some components
(e. g. RMIC) have no public API at all. So it's hard to plug just one
public method from one implementation to another without modifying
non-public code - and non-public code could have (and probably does
have) very different structure in different implementations.

What we really can do is try to run both these implementations and
compare them for conformance to the specification, compatibility with
reference implementation, maybe stability, performance, visual code
quality etc. I'm now planning to do some of these, so we'd get some
results pretty soon.

 Vasily


-----Original Message-----
From: Mikhail Loenko [mailto:mloenko@gmail.com]
Sent: Friday, April 14, 2006 7:53 AM
To: harmony-dev@incubator.apache.org
Subject: Re: Contribution of RMI framework

I think we need compare contributions method by method to assemble
the best classlib

Thanks,
Mikhail

2006/4/14, Daniel Gandara <danielgandara@neosur.com>:
> Vasily,
>        good to know that there is someone out there who has also
> been working on rmi; I believe we'll have a lot to share and discuss
>  about it.
>
> Thanks,
>
> Daniel
>
> ----- Original Message -----
> From: "Zakharov, Vasily M" <vasily.m.zakharov@intel.com>
> To: <harmony-dev@incubator.apache.org>
> Sent: Wednesday, April 12, 2006 9:53 PM
> Subject: Contribution of RMI framework
>
>
> Hi, all,
>
> I would like to announce the next code contribution to Harmony project
> on
> behalf of Intel corporation. This contribution contains the
> implementation
> of RMI framework.
>
> The archive with this contribution can be found at:
>
> http://issues.apache.org/jira/browse/HARMONY-337
>
> The Remote Method Invocation (RMI) framework enables an object in one
> virtual machine to call methods of an object in another one, to create
> applications distributed on various Java virtual machines on the same
> or different hosts.
>
> For more information please see the documentation contained in the
> bundle.
>
> The code is a result of efforts of Intel Middleware Product Division
> team.
> One should be able to run this code with a 1.4+ compatible JRE/VM (was
> tested using commercial VMs). No classes require special support from
> the VM.
> All code is pure Java. The implementation is done according to Java
1.4
> specification of RMI.
>
> The archive contains the README file that explains the building and
> running
> process for this code. If any additional comments or clarifications
are
> needed, feel free to contact me. I will be happy to answer all
questions
> about this contribution and to participate in its further
> development/maintenance and integration into Harmony.
>
> Vasily Zakharov
> Intel Middleware Product Division
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message