Archived

This forum has been archived. Please start a new discussion on GitHub.

what will happen after reconnecting

I want to know what Ice will do if nodes lost connection to icegridregister for a long time.

Does ice reconnect automatically? I notice sometimes I have to restart icegridnode. Can it reconnect without people interference ?

Comments

  • benoit
    benoit Rennes, France
    Hi,

    Yes, the IceGrid node will try to re-connect to the registry automatically. You shouldn't have to restart it.

    If the node doesn't reconnect automatically for you, you should provide more information so that we can help you figuring out what is the issue. Which Ice version and OS do you use? Could you try to enable tracing on the node (with the Ice.Trace.Network=2 and Ice.Trace.Protocol properties for example)?

    Cheers,
    Benoit.
  • I use the config file similiar as the sample of icegrid. Therefore I didn't use Ice.Trace.Network=2 and Ice.Trace.Protocol before.

    I tried to run an icegridnode in my machine. It ran well in the beginning. Then I disconnected my network. It didn't show any exception. I guess it could be OK if I re-connected the network. I left my office. Today morning, I found it throws many same exceptions:

    icegridnode: warning: couldn't contact the IceGrid registry:
    .\Network.cpp:675: Ice::ConnectFailedException:
    connect failed: WSAEHOSTUNREACH

    even though I built network connection again, it still couldn't get contact with registry.
  • matthew
    matthew NL, Canada
    even though I built network connection again, it still couldn't get contact with registry.

    Is the registry still reachable? Try telnet to the host & port that the registry is using. If it is, then there is no reason why the Ice client cannot connect. If it is not reachable then you have misconfigured the network or there is some other networking related problem.
  • The registry is still reachable. I restarted icegridnode. and nothing was wrong in the moring. I just made a test. all things were fine. The only trouble was that I disconnected network. But after a night, icegridnode threw exceptions serveral time and could not re-connect.
  • benoit
    benoit Rennes, France
    Hi,

    What happens when you reconnect your machine to the network? Does the node stop printing warnings or does it continue printing the warnings?

    If it stops printing the warnings, can you try the "node describe <your node name>" command with the icegridadmin tool? If it shows the correct information for your node, can you try the "node ping <your node name>" command?

    Also, does the IP address of your machine might have changed when you reconnect it to the network?

    Cheers,
    Benoit.
  • There should be no problem. As I have run Icegrid in our system for a bit long time. I disconnected for experiment. After I re-connected, everything seems OK. I used icegridGUI, and it detected the node immediately. Of course it throws no exception as I described before.

    I got a message like this "warning: unknown property: Freeze.DbEnv.192.168.1.184.DbHome". Because we don't set anyting about Freeze, very node get such warning when running. It seems no harm to our system. By the way the ip address of my machine keeps the same.

    Can anyone do as I did? just cut off network for a night to see what will happen?

    /// this is node.config

    IceGrid.InstanceName=MyGrid

    #
    # The IceGrid locator proxy.
    #
    Ice.Default.Locator=MyGrid/Locator:tcp -h 192.168.1.114 -p 12000

    #
    # IceGrid node configuration.
    #
    # node.name要和*.xml里面的node定义一致
    #IceGrid.Node.Name=192.168.1.51
    IceGrid.Node.Endpoints=default
    IceGrid.Node.Data=db/node
    #IceGrid.Node.Output=db
    #IceGrid.Node.RedirectErrToOut=1

    #
    # Trace properties.
    #
    IceGrid.Node.Trace.Activator=3
    IceGrid.Node.Trace.Patch=1
    #IceGrid.Node.Trace.Adapter=2
    #IceGrid.Node.Trace.Server=3


    /// this is registry.config

    IceGrid.InstanceName=MyGrid

    #
    # IceGrid registry configuration.
    #
    IceGrid.Registry.Client.Endpoints=default -p 12000
    IceGrid.Registry.Server.Endpoints=default
    IceGrid.Registry.Internal.Endpoints=default
    IceGrid.Registry.Admin.Endpoints=default
    IceGrid.Registry.Data=db/registry
  • matthew
    matthew NL, Canada
    You should turn on network tracing to find out what the issue is.

    Ice.Trace.Network=2

    This will tell you the IP address and port that the node and registry are using. It will also tell you what IP address and port they attempt to establish connections with.
  • I did as recommended. and I found that the reason is that after rebuilding network connection, it takes a little bit long time for icegridnode to register again, about 10 minutes or more in my machine.

    Is there any setting make this quick (IceGrid.Registry.NodeSessionTimeout or whatever)? and is there any side-effects?

    I also try to restart ice registry. Icegridnode can still reconnect to registry. But it takes very long time. As I showed in 7#, I use a registry.config for Ice.Config with almost all default settings. while the previous config is like this:

    IceGrid.InstanceName=MyGrid
    #
    # IceGrid registry configuration.
    #
    IceGrid.Registry.Client.Endpoints=default -p 12000
    IceGrid.Registry.Server.Endpoints=default
    IceGrid.Registry.Internal.Endpoints=default
    IceGrid.Registry.Admin.Endpoints=default
    #IceGrid.Registry.Admin.Endpoints=tcp -h localhost -p 12001
    IceGrid.Registry.Data=db/registry

    # changed configuration
    IceGrid.Registry.Admin.ThreadPool.Size=50
    IceGrid.Registry.Admin.ThreadPool.SizeMax=100
    IceGrid.Registry.Admin.ThreadPool.SizeWarn=10
    IceGrid.Registry.AdminSessionTimeout=3600
    IceGrid.Registry.Client.ThreadPool.Size=50
    IceGrid.Registry.Client.ThreadPool.SizeMax=100
    IceGrid.Registry.Client.ThreadPool.SizeWarn=10
    IceGrid.Registry.Internal.ThreadPool.Size=50
    IceGrid.Registry.Internal.ThreadPool.SizeMax=100
    IceGrid.Registry.Internal.ThreadPool.SizeWarn=10
    IceGrid.Registry.NodeSessionTimeout=3600
    IceGrid.Registry.Server.ThreadPool.Size=50
    IceGrid.Registry.Server.ThreadPool.SizeMax=100
    IceGrid.Registry.Server.ThreadPool.SizeWarn=10

    does the previous config file still have some influence.
  • benoit
    benoit Rennes, France
    Hi,

    You have set the node session timeout to 1 hour (3600s). This means two things:
    • The registry will consider the node dead if it didn't receive a keep alive message from the node within the hour.
    • If the node is connected to the registry, it will send keep alive messages every 30 minutes (the node session timeout divided by 2). If the node is not connected to the registry (your case), it will try to connect to the registry only every 30 minutes.

    Why did you set such a large value? You should either not set it and use the default value or set it to something small (less than one minute). The same applies for the admin session timeout (which is used by the IceGrid admin GUI).

    Btw, is there also a special reason why you had to change the thread pool size configuration of the registry?

    Cheers,
    Benoit.
  • although now I use config file showed in #7 now. But because I used a config file showed in #9 before, the config like "IceGrid.Registry.AdminSessionTimeout=3600" has saved to icegrid regisrty database or file or whatever. Therefore, even I restart registry the previous config is still valid. Is it true ?

    By the way, the config is used by some guy left my project. I guess he just want to try something.
  • benoit
    benoit Rennes, France
    No, the configuration isn't saved into the database. It's read each time you restart the registry or node. You should be able to see the node keep alive messages sent to the registry by enabling node tracing on the registry with the property IceGrid.Registry.Trace.Node set to 3.

    If you use the default value for IceGrid.Registry.NodeSessionTimeout, it shouldn't take 10 minutes for the node to reconnect to the registry. Could please post the registry node traces and the node network traces if that's still the case?

    Cheers,
    Benoit.
  • yes, you are right. we make some confusing.