tests with rmic

tests with rmic

[Nicolas Geoffray]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

Hi everyone,

I found what might be a bug in gnu classpath and I would like to commit 
a testlet in mauve. The thing is, my test involves compiling with rmic 
and launching two gnu classpath jvms. I never commited in mauve, but 
seeing other testlets, i didn't found ways to commit such a test.

I attached the files. This is how you launch the test:

gcj -C Main.java
gcj -C ReceiveObject.java
gcj -C ReceiveObjectImpl.java
rmic ReceiveObjectImpl

rmiregistry &
jamvm ReceiveObjectImpl &
jamvm Main


Any suggestions?

Thanks,
Nicolas

[-- Attachment #2: Main.java --]
[-- Type: text/x-java, Size: 443 bytes --]

import java.rmi.Naming;

public class Main{

  class Foo implements java.io.Serializable{}

  class Bar implements java.io.Serializable{
    Foo f = new Foo();
  }
    
  public static void main(String[]args){

    try{
      Bar b = new Bar();
      ReceiveObject ref = (ReceiveObject) Naming.lookup("rmi://localhost/ReceiveObject");
      ref.receiveObject(b);
    }catch(Exception e){
      System.out.println("Error : " + e );
    }
  }
}

[-- Attachment #3: ReceiveObject.java --]
[-- Type: text/x-java, Size: 179 bytes --]

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface ReceiveObject extends Remote{
  public Object receiveObject(Object unknown)
		throws RemoteException;
}

[-- Attachment #4: ReceiveObjectImpl.java --]
[-- Type: text/x-java, Size: 535 bytes --]

import java.rmi.*;
import java.rmi.server.*;


public class ReceiveObjectImpl extends UnicastRemoteObject implements ReceiveObject{

  public ReceiveObjectImpl() throws RemoteException{
  }

  public Object receiveObject(Object unknown)
    throws RemoteException{
      System.out.println(unknown);
      return null;
    }

  public static void main(String[] args){
    try{
      ReceiveObject ref = new ReceiveObjectImpl();
      Naming.rebind("ReceiveObject", ref);
    }catch(Exception e){
      e.printStackTrace();
    }
  }
}

Re: tests with rmic

[Chris Abbey]

On Monday 17 October 2005 12:13, Nicolas Geoffray wrote:
> rmiregistry &
> jamvm ReceiveObjectImpl &
> jamvm Main
>
> Any suggestions?

Mauve style guidelines aside (because I have no idea what they would encourage 
here), I'd encourage you not to start the default rmiregistry in any test 
framework, as it creates a dependency on the runtime environment. 
(Specifically that whoever is running the testcase doesn't already have an 
rmi registry up.) Instead, I'd suggest that the ReceiveObjectImpl class binds 
your own registry to an off the wall port that you've selected, and then in 
the test case, you locate on that same port. This does create the problem 
that you'll have to pick a port that's not in use, one solution to that is to 
use a fallback pattern to select the port and write it to a file that the 
test case loads to find out where the registry is. Also, by creating the 
registry in the test server, you ensure that it goes away when the test is 
done. The test server should also have a dead man's switch to exit after a 
finite amount of time, otherwise you have to try to ensure some cleanup 
externally, and most of the ways I've seen of doing that have some *bad* side 
effects. (case in point at work, we have a few very large shared development 
machines, occasionally, folks would get failures in some of the test buckets 
they were running that just didn't make sense... further digging found a test 
case like this that wanted to clean up after itself, so it did a ps list and 
killed any task with it's name in it. This works fine as long as there is 
only one instance of the test suite running. Another routinely killed the 
snmpd on the system, because the test case fired up it's own with a unique 
config, on the default port, and then when the test failed because it was 
running iwht the wrong snmpd config, it blasted all instances of snmpd on the 
box.)  Anyway, client/server test cases usually need some extra thought put 
into them was my only point before I started rambling.

/me re-lurks now.

-- 
Never make a technical decision based upon the politics of the situation.
Never make a political decision based upon technical issues.
The only place these realms meet is in the mind of the unenlightened.
			-- Geoffrey James, The Zen of Programming

Re: tests with rmic!

[Meskauskas Audrius]

Hi, Nicolas,

Nice idea, great to have at least any java.rmi rests! The current 
testing situation with this package is deeply tragical, the coverage 
being plain zero. And it is possible to find random talks on the web 
like "how reliable they (GNU Classpath) RMI implementation is? Does it 
work?".

Any tests are very welcome.

I think it would be a good idea to write Mauve tests as the independent 
modules that run on a single virtual machine and does call external 
tools. The most of the current tests  are written this way. Here are 
several suggestions how to make an ordinary Mauve test that would not 
need to cross the boundaries of the current virtual machine to run:

1. Instead of starting three independent virtual machines (one for 
server, one for client and one for the naming service), you can just 
start three threads. When all cleanup problems, if any, will be 
restricted to the current run of the test suite.
2. Instead of invoking rmic from inside the Mauve test, run it once with 
the -keep key and just add the generated source code file to your path. 
Such test would be easier to debug.
3. When all threads are together and can share static variables, all 
cleanup is trivial (use try {}  finally { clean }).

Nicolas Geoffray wrote:

> Hi everyone,
>
> I found what might be a bug in gnu classpath and I would like to 
> commit a testlet in mauve. The thing is, my test involves compiling 
> with rmic and launching two gnu classpath jvms. I never commited in 
> mauve, but seeing other testlets, i didn't found ways to commit such a 
> test.
>
> I attached the files. This is how you launch the test:
>
> gcj -C Main.java
> gcj -C ReceiveObject.java
> gcj -C ReceiveObjectImpl.java
> rmic ReceiveObjectImpl
>
> rmiregistry &
> jamvm ReceiveObjectImpl &
> jamvm Main
>
>
> Any suggestions?
>
> Thanks,
> Nicolas
>
>------------------------------------------------------------------------
>
>import java.rmi.Naming;
>
>public class Main{
>
>  class Foo implements java.io.Serializable{}
>
>  class Bar implements java.io.Serializable{
>    Foo f = new Foo();
>  }
>    
>  public static void main(String[]args){
>
>    try{
>      Bar b = new Bar();
>      ReceiveObject ref = (ReceiveObject) Naming.lookup("rmi://localhost/ReceiveObject");
>      ref.receiveObject(b);
>    }catch(Exception e){
>      System.out.println("Error : " + e );
>    }
>  }
>}
>  
>
>------------------------------------------------------------------------
>
>import java.rmi.Remote;
>import java.rmi.RemoteException;
>
>public interface ReceiveObject extends Remote{
>  public Object receiveObject(Object unknown)
>		throws RemoteException;
>}
>  
>
>------------------------------------------------------------------------
>
>import java.rmi.*;
>import java.rmi.server.*;
>
>
>public class ReceiveObjectImpl extends UnicastRemoteObject implements ReceiveObject{
>
>  public ReceiveObjectImpl() throws RemoteException{
>  }
>
>  public Object receiveObject(Object unknown)
>    throws RemoteException{
>      System.out.println(unknown);
>      return null;
>    }
>
>  public static void main(String[] args){
>    try{
>      ReceiveObject ref = new ReceiveObjectImpl();
>      Naming.rebind("ReceiveObject", ref);
>    }catch(Exception e){
>      e.printStackTrace();
>    }
>  }
>}
>  
>

Re: tests with rmic!

[Nicolas Geoffray]

Hi Meskauskas,

Meskauskas Audrius wrote:

> Hi, Nicolas,
>
> Nice idea, great to have at least any java.rmi rests! The current 
> testing situation with this package is deeply tragical, the coverage 
> being plain zero. And it is possible to find random talks on the web 
> like "how reliable they (GNU Classpath) RMI implementation is? Does it 
> work?".
>
> Any tests are very welcome.
>
> I think it would be a good idea to write Mauve tests as the 
> independent modules that run on a single virtual machine and does call 
> external tools. The most of the current tests  are written this way. 
> Here are several suggestions how to make an ordinary Mauve test that 
> would not need to cross the boundaries of the current virtual machine 
> to run:
>
> 1. Instead of starting three independent virtual machines (one for 
> server, one for client and one for the naming service), you can just 
> start three threads. When all cleanup problems, if any, will be 
> restricted to the current run of the test suite.

I can't use threads in a same virtual machine, because there is no 
serialization of objects in RMI when the server and the client lives in 
the same virtual machine (maybe it's possible enabling a flag somewhere, 
but i don't know the API)

> 2. Instead of invoking rmic from inside the Mauve test, run it once 
> with the -keep key and just add the generated source code file to your 
> path. Such test would be easier to debug.

Allright. Good idea

Bye,
Nicolas

Re: tests with rmic

[Meskauskas Audrius]

 >I can't use threads in a same virtual machine, because there is no 
serialization of objects in RMI when the server and the client lives in 
the same virtual machine (maybe it's possible enabling a flag somewhere, 
but i don't know the API)

I looked at our gnu.java.rmi.server.UnicastRef and - yes, unfortunately 
it seems that there is system property in Classpath that would force the 
object serialization even if the RMI client and server are in the same 
machine.

If you plan serious testing work, we should probably add such property 
as a necessary testing tool, but altering RMI implementation requires to 
have a test suite first. I think, you can commit such tests anyway 
because the object serialization is not the only thing in RMI that 
deserves testing.

Audrius.

Re: tests with rmic

[Nicolas Geoffray]

Hi Audrius

Meskauskas Audrius wrote:

>
> I looked at our gnu.java.rmi.server.UnicastRef and - yes, 
> unfortunately it seems that there is system property in Classpath that 
> would force the object serialization even if the RMI client and server 
> are in the same machine.
>
> If you plan serious testing work, we should probably add such property 
> as a necessary testing tool, but altering RMI implementation requires 
> to have a test suite first. I think, you can commit such tests anyway 
> because the object serialization is not the only thing in RMI that 
> deserves testing.
>
Unfortunately I do not plan for the moment serious rmi testing work. I 
just wanted to report a bug within gnu classpath. Because the test 
involves launching at least 2 vms, it's difficult to reveal the bug. The 
property forcing serialization would be great in my case!

Cheers,
Nicolas