RE: problem with deployment

Sai,
 
This is not a SmartFrog problem,  the problem is almost certainly a Xen networking issue, most likely to do with the setting up of the bridges and the multicasts that binds them together. It appears that one end is not behaving correctly.
 
We have talked to our Xen experts and they state that this kind of asymetric reachability problem is not unknown. They suggest that you use the tool "ethereal" to inspect the packets that the xen nodes are exchanging to diagnose the problem.
 
Sorry we cannot be of more help without direct access to your nodes, but this really is not our area. 
 
Patrick


________________________________

From: [email protected] [mailto:[email protected]] On Behalf Of Dharanikota, Sai
Sent: 22 February 2005 15:26
To: [email protected]; Guijarro, Julio
Subject: RE: [Smartfrog-developer] problem with deployment



Hi Julio,

 

My problem is the communication between the daemons. Once the daemons are communicating well I am able to do the operations( sfstart, sfrun, deploy etc).I want to explain the problem again.

I just have two 2 daemons running on two machines and I want to test the communication between the daemons. The steps I followed are described below

 

1) I started sfDaemon on both the machines "knscsl020" and  

   "knscsl018". 

       2) When I try to open the sfmngconsole for knscsl020 from

 knscsl018. 

 3) When I try to open the sfmngconsole for knscsl018 from knscsl020. 

  

    

 

 Observation:

 

  

 

 When I follow the steps 1, 2 I get the exception

 "java.net.ConnectException" after step 2.

 

  

 

 When I follow the steps 1, 3 I could able to access the sfmngconsole for

 knscsl018 from knscsl020 and I could able to see the deployed

 components.

 

  

 

 When I follow the steps 1, 3, 2 the daemons are communicating properly

 and I could able to access sfmngconsole for knscsl020 from knscsl018 and

 sfmngconsole for knscsl018 from knscsl020. I am also able to see the

 deployed components on both the machines.

 

  

 

 My observation is: every time I have to do 1, 3, 2 for the daemon

 communication to be proper which should not be the case. If I follow 1,

 2, 3 the communication is not proper.

 

 Once both the daemons are able to communicate then I am able to deploy

 the components from one machine to other machine.

 

 

 

________________________________

From: Guijarro, Julio [mailto:[email protected]] 
Sent: Thursday, February 17, 2005 8:35 PM
To: Dharanikota, Sai; [email protected]
Subject: RE: [Smartfrog-developer] problem with deployment

 

Sai, 

 

Every SF daemon (root ProcessCompound) starts its own registry using port 3800 by default. The registry is only used to locate the daemon running in a particular machine.

 

When you want to deploy a SF description a new ProcessCompound (PC) is created. The PC will try to locate the daemon where the deployment will happened. To locate the daemon it will use the “hostname” provided and once the daemon is located it will pass to it the description that has to be deployed. Resuming, it is very similar to the simple RMI example that I provided to test RMI communications in you machines.

 

Now, lets go back to your problem:

 

[root@knscsl020 opt]# sfStart knscsl018 ex1 org/smartfrog/examples/helloworld/example1dist.sf

2005/02/07 17:23:27:929 CET [WARN ][main] SFCORE_LOG - SmartFrog security is NOT active

Warning: stack trace logging enabled

SmartFrog 3.04.014_beta

(C) Copyright 1998-2004 Hewlett-Packard Development Company, LP QUIET

SmartFrogException:: java.rmi.ConnectException:

Connection refused to host: 127.0.0.1; nested exception is: 

        java.net.ConnectException: Connection refused,

cause: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: 

        java.net.ConnectException: Connection refused

 

 

 

This problem is solved when the daemons communicate properly. But to make the daemons communicate properly I have to follow the strange sequence of steps which I described previously.

 

 

When you run this example (I assume that you have modified hostA and hostB in the example to match your machine names), 

 

yes

 

the sfStart command starts a ProcessCompound that tries to locate the local host daemon and to pass the description to it. The error that you get tells you that the sfStart ProcessCompound could not contact with the local daemon (RMI connection was refused). 

 

Please don’t start or run any examples let us test the communication between the daemons

When the daemons start communicating fine this error doesn’t occur. But to make the daemons communicate properly I have to follow the strange sequence of steps which I described previously

 

This error happens even before any external communication occurs and tells me that there is probably a problem in the local host. 

 

This error usually occurs when a local daemon is not present but you told me that you had two daemons, one running in each machine, before trying the SFStart and that is what confuses me.

 

There is a daemon running on each machine.

 

 

Regards

Sai 

________________________________

From: Dharanikota, Sai [mailto:[email protected]] 
Sent: 17 February 2005 13:44
To: Guijarro, Julio; [email protected]
Subject: RE: [Smartfrog-developer] problem with deployment

 

Hello Julio,

 

My question is regarding the way of communication between the daemons as I described in my previous mail.

I am able to execute the examples perfectly once the daemons are able to communicate. I don’t understand where the problem lies. For me the example which you have sent looks similar to “generator and printer” example.  If the problem is with the rmi or network then the examples shouldn’t execute at all and the components cannot be deployed. But that’s not the case. Before trying to execute and deploy some components let me be clear with the daemon communication ( the way one daemon initiates other daemon is strange to me.).

 

Regards

Sai

 

From: Guijarro, Julio [mailto:[email protected]] 
Sent: Wednesday, February 16, 2005 11:59 PM
To: Dharanikota, Sai; [email protected]
Subject: RE: [Smartfrog-developer] problem with deployment

 

Hi Sai,

 

I don’t see anything wrong in any of the information that you sent but you are using JAVA 1.5 and we haven’t extensively test SF with it. I would recommend you to use 1.4.2 instead.

 

I think you have some networking configuration either in the switch or the network stack. We have run SF with Xen in many different configurations and we have never experienced a similar problem.

 

Something you could do to eliminate options is to run a simple RMI program. 

 

Please, let me know if the example works in the situation you described previously.

 

You can find a simple example in:

http://yama-linux.cc.kagoshima-u.ac.jp/~yamanoue/researches/java/rmi-ex2/

 

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

 

A Simple Java RMI example

 

Takashi Yamanoue <http://yama-linux.cc.kagoshima-u.ac.jp/../~yamanoue/index.html> , [email protected] 

 

-      The client program(RmiClient.class) sends a message to the server program(RmiServer.class). The server program print out the message on the console.

 

 

 

-      This example consists of the following files

*     MessageReceiverInterface.java

*     This part defines the RMI interface. The method (receiveMessage) of the server class, which implements this interface, is called from the remote client. In the remote client program, the type of the server class (which is the remote class in this client class) is this interface.

*     RmiServer.java

*     This is the server program(class). In this class, the method “receiveMessage”, which is called from the remote client, is defined. This class is the implementation of the RMI interface.

*     RmiClient.java

*     This is the client program(class). The remote method is called from this class.

 

-      Execution outline

1.   RmiServer creates the “registry”. This is a kind of dictionary. Its key is a name (which is the ID of a remote object) and its content is an object. This object is looked up from a remote program by the name. This registry is accessed from a remote object by the IP address (or host name) and the port number.

2.   RmiServer binds the name “rmiServer” and it-self(RmiServer.class) in the registry.

 

3.   RmiClient looks up the remote object (RmiServer) by the name “rmiServer”.

 

 

4.   RmiClient calls the method “receiveMessage” of the RmiServer class.

5.   The method “receiveMessage” of the RmiServer class prints out the message.

 

-      Compile

1.   javac RmiServer.java

2.   rmic RmiServer

3.   javac RmiClient.java

 

-      Execution

1.   (at one host,) java RmiServer

2.   (at another host) java RmiClient <server’s address> 3232 <message text>

-      The source codes

ReceiveMessageInterface.java

 

    import java.rmi.*;

public interface ReceiveMessageInterface extends Remote

{

    　　　　　　　void receiveMessage(String x) throws RemoteException;

　　　　　　}

 

RmiServer.java

 

import java.rmi.*;

import java.rmi.registry.*;

import java.rmi.server.*;

import java.net.*;

 

public class RmiServer extends java.rmi.server.UnicastRemoteObject

implements ReceiveMessageInterface 

{

    int      thisPort;

    String   thisAddress;

    Registry registry;    // rmi registry for lookup the remote objects.

 

    // This method is called from the remote client by the RMI.

    // This is the implementation of the “ReceiveMessageInterface”.

    public void receiveMessage(String x) throws RemoteException

    {

        System.out.println(x);

    }

 

    public RmiServer() throws RemoteException

    {

           try{

            // get the address of this host.

               thisAddress= (InetAddress.getLocalHost()).toString();

           }

           catch(Exception e){

            throw new RemoteException("can't get inet address.");

        }

thisPort=3232;  // this port(registry’s port)

        System.out.println("this address="+thisAddress+",port="+thisPort);

        try{

        // create the registry and bind the name and object.

           registry = LocateRegistry.createRegistry( thisPort );

            registry.rebind("rmiServer", this); 

        }

        catch(RemoteException e){

           throw e;

        }

    }

       

    static public void main(String args[])

    {

        try{

           RmiServer s=new RmiServer();

       } 

       catch (Exception e) {

           e.printStackTrace();

           System.exit(1);

       }

     }

}

 

RmiClient.java

 

import java.rmi.*;
import java.rmi.registry.*;
import java.net.*;

public class RmiClient
{
    static public void main(String args[])
    {
       ReceiveMessageInterface rmiServer;
       Registry registry;
       String serverAddress=args[0];
       String serverPort=args[1];
       String text=args[2];
       System.out.println("sending "+text+" to "+serverAddress+":"+serverPort);
       try{
           // get the “registry” 
           registry=LocateRegistry.getRegistry(
               serverAddress,
               (new Integer(serverPort)).intValue()
           );
           // look up the remote object
           rmiServer=
              (ReceiveMessageInterface)(registry.lookup("rmiServer"));
           // call the remote method
           rmiServer.receiveMessage(text);
       }
       catch(RemoteException e){
              e.printStackTrace();
       }
       catch(NotBoundException e){
           e.printStackTrace();
       }
    }
}

 

________________________________

-      References

1.   Trail: RMI ,  in The JavaTM Tutorial, http://java.sun.com/docs/books/tutorial/rmi/

A brief overview of the RMI system and then walks through a complete client/server example that uses RMI's unique capabilities to load and to execute user-defined tasks at runtime.

2.   Java Remote Method Invocation (Java RMI), http://java.sun.com/products/jdk/rmi/

 

 

________________________________

From: [email protected] [mailto:[email protected]] On Behalf Of Dharanikota, Sai
Sent: 14 February 2005 13:12
To: Guijarro, Julio; [email protected]
Subject: RE: [Smartfrog-developer] problem with deployment

 

Hi Julio,

 

These are the test results and I am attaching the files which contains the settings.

 

________________________________

From: Guijarro, Julio [mailto:[email protected]] 
Sent: Friday, February 11, 2005 11:15 AM
To: Dharanikota, Sai; Goldsack, Patrick; [email protected]
Subject: RE: [Smartfrog-developer] problem with deployment

 

Hi Sai,

 

This is a very strange error. We have never experienced a similar problem. We think it must be a networking setup issue. Could you complete the following questions?

 

-   Are the two machines connected to the same switch or hub or are they in different subnets?

 

The machines are connected to the same switch and they are in the same subnet.

 

-   Could you try if “NSLookup” works for both machines?

 

NSLookup works for both machines

 

-   What OS do you run in these machines?

 

 

We are currently running “Linux” ported on “Xen virtual machine monitor”( Xen is a resource virtualization software that sits between Linux and the actual hardware).

 

-   The SF daemon uses port 3800 for its RMI registry. Could you try to telnet into that port to see if is reachable before you try to deploy anything.

 

I could able to telnet into the port 3800 before I try to deploy the components.

 

-    Just for completeness of info, could you send us the various settings that the sf display gives you on the help menu (help->info and help->info prop). You can save or copy the results in a file. Please, do this for both hosts.

 

I have attached the files which contains the setting on the individual machines.

 

I none of it tells us where the problem is we will think up some diagnostic tests…!

 

Julio Guijarro

 

 

Sai