Archived

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

Callbacks in Glacier2

Hello!

I am developing a render grid under the architecture of a multi-agent system, in which main services are located through IceGrid and agents are in Internet. I use Glacier2 to allow agents to contact with the main services, and I use callbacks to permite main services to notify new works to agents.

When a service (Service A) notifies a new work to an agent, this agent gets the notification correctly, but it locks itself when it tries to get data from another service (Service B: different to the Service A, which notifies the work). This last action is performed when the callback is done by the ServiceA.

I enable the log, but it doesn't appear any conflict.

An important question is that agents are subscribed to the Service A previously, and this subscription consists in that an agent supplies a proxy to the callback object. This way, Service A can iterate through its list of agents and it can notify the new work. I am confused with this approach, and I don't know if it is a correct form of operate in such context.

I would like to use callbacks because agents will be behind a firewall and callbacks allow me to solve the problem which represents an hostile network environment.

Thank you very much,
David.

Comments

  • matthew
    matthew NL, Canada
    What version of Ice are you using? What operating system? A diagram of the calling sequence and where the various services are located in the network particularly in respect to inside/outside of the firewall would be helpful.
  • I use Debian Sid, Ice 3.1.0, and Python.

    Currently, I am developing the system in my notebook, which is in a local area composed of three computers behind a firewall. Therefore, all the services and the agents are being executed in my notebook. I have forwarded the port 8000 to Glacier2, which is executed in my notebook (192.168.1.4).

    This is the calling sequence:

    1.- An agent starts up and execute the operation 'subscribe' of the service A:

    interface Master {
    ....
    void subscribe(string agentName, RenderAgent* agent);
    ....
    };

    2.- The service A has a dictionary <agentName, prxAgent> and add the new entry.

    3.- A new work is notified to the service A. Then, the service A notifies the new work to its subscribed agents:

    interface RenderAgent {
    ....
    void notifyNewWork(TZones zones, int idWork, int benchmarkValue);
    ....
    };

    4.- An agent tries to get data from the service B. It uses the registry of the IceGrid service to resolve indirect proxies. This is the interface of the service B:

    interface ModelRepository {
    ....
    nonmutating string get(int idModel, out ByteSeq model);
    ....
    };

    5.- The agent locks in this step.

    This is the glacier2router config file:

    Glacier2.Client.Endpoints=tcp -h 192.168.1.4 -p 8000
    Glacier2.Client.PublishedEndpoints=tcp -h ladorada.dyndns.org -p 8000
    Glacier2.Server.Endpoints=tcp -h 192.168.1.4
    Glacier2.CryptPasswords=config/passwords.cfg
    Ice.Default.Locator=IceGrid/Locator:tcp -h 127.0.0.1 -p 10000

    #Other properties
    Ice.Trace.Network=2
    Ice.MessageSizeMax=20480

    And this is the agent config file:

    Ice.Default.Router=Glacier2/router:tcp -h ladorada.dyndns.org -p 8000
    MyAdapter.Router=Glacier2/router:tcp -h ladorada.dyndns.org -p 8000

    Ice.ACM.Client=0
    Ice.MonitorConnections=60
    Ice.RetryIntervals=-1
    Ice.Trace.Network=2
    Ice.MessageSizeMax = 20480
    Ice.Warn.Connections=1

    Thank you,
    David.
  • matthew
    matthew NL, Canada
    I suspect you need to increase the size of the client side thread pool in the agent. Try setting:

    Ice.ThreadPool.Client.Size=<some value more than 1>

    You can read more about this in the Ice manual in section 34.7.
  • Your suspicions are well-founded.

    Thank you,
    David.