IceGrid with bidir clients (wastes connections to IceGrid Registry)

LeonardoLeonardo Member Alexander SafonovOrganization: Prime LtdProject: StubIt x86/x64 - distributed software protection
Hi.

I'm trying to configure IceGrid to work with my bidir clients. Clients uses configs with Ice.ACM.Client=0. But I have a problem - my clients also stay connected to IceGrid Registry cause ACM was disabled in client side. This wastes connections to IceGrid Registry.
To solve this problem I try to use Ice.ACM.Server=10 in IceGrid Registry config but I have other problems with it - admin tools will be disconnected after 10 seconds of idleness and IceGrid Nodes also reconnects every 10 seconds to IceGrid Registry.

Please tell me how to configure clients and IceGrid properly in this situation.

Comments

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    You can set the Ice.ACM.Server property to a value which is for example twice the value of the IceGrid.Registry.SessionTimeout value (whose default value is 30). This should make sure client connections are eventually closed and ensure they won't be closed too soon.

    Cheers,
    Benoit.
  • LeonardoLeonardo Member Alexander SafonovOrganization: Prime LtdProject: StubIt x86/x64 - distributed software protection
    benoit wrote: »
    Hi,

    You can set the Ice.ACM.Server property to a value which is for example twice the value of the IceGrid.Registry.SessionTimeout value (whose default value is 30). This should make sure client connections are eventually closed and ensure they won't be closed too soon.

    Cheers,
    Benoit.

    Hello,
    Thank you.
    We have very strict performance requirements. In order to provide maximum grid performance we need configure grid to match following points:
    1. minimize the number and lifetime of unnecessary connections between clients and grid controller. I. e. after the client received the node address (from grid controller), controller close client connection immediately (or a short amount of time <1 second);
    2. eliminate disconnections between the grid controller and managed grid nodes (grid nodes automatically restore the connection after it closed controller timeout, this affects the overall grid performance);
    3. at the same time we need to ensure ease of administration, i. e. eliminate disconnections of administrative tools from grid controller by timeout.
    Is there way to configure the grid, to match the points above?
    For example, can we configure IceGrid registry Ice.ACM.Server to minimal timeout = 1 second and have an administrative tools and grid nodes permanently connected to controller w/o reconnection (not affected by this small timeout)?
    Thanks for your participation.
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Alexander,

    The IceGrid nodes establish sessions with the IceGrid registry(ies), and likewise IceGrid administrative clients (such as the IceGrid GUI) establish sessions with the IceGrid registry. The corresponding session timeouts are IceGrid.Registry.NodeSessionTimeout and IceGrid.Registry.SessionTimeout.

    As Benoit indicated, you could set Ice.ACM.Server in your IceGrid Registry to a value greater than these timeouts to make sure these sessions/connections remain open while plain client-to-IceGrid registry connections are closed automatically when idle.

    That said, I would not worry too much about client to IceGrid registry connections staying open for a few extra seconds or even minutes: Ice can easily scale to a very large number of connections, as illustrated in our Performance and Scalability article.

    Also, if you have a very large number of clients, there is a good chance your clients will connect to your servers over the Internet. In this case, you would most likely have Glacier2 routers between your clients and servers, and only the Glacier2 routers (not the clients) would establish connections to your IceGrid registry(ies).

    Best regards,
    Bernard
  • LeonardoLeonardo Member Alexander SafonovOrganization: Prime LtdProject: StubIt x86/x64 - distributed software protection
    bernard wrote: »
    Hi Alexander,

    ...

    As Benoit indicated, you could set Ice.ACM.Server in your IceGrid Registry to a value greater than these timeouts to make sure these sessions/connections remain open while plain client-to-IceGrid registry connections are closed automatically when idle.

    ...

    Best regards,
    Bernard

    Bernard, thank you for a reply. This solution seems to be applicable in our project.
    Do I understand right what at this moment IceGrid does not support a separate timeout configuration for the plain client-to-IceGrid Registry connections (for ex. IceGrid.Registry.ClientTimeout) other than Ice.ACM.Server timeout?

    Regards, Alexander.
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi Alexander,

    Right, it's not possible to have distinct ACM timeout values for client connections and administrative client connections. As Bernard pointed out, Ice can scale to a very large number of connections so it shouldn't be an issue if your client connections to IceGrid remain open for few minutes (it might even be beneficial if your clients need to make several invocations to IceGrid to retrieve endpoints).

    Cheers,
    Benoit.
  • LeonardoLeonardo Member Alexander SafonovOrganization: Prime LtdProject: StubIt x86/x64 - distributed software protection
    benoit wrote: »
    Hi Alexander,

    Right, it's not possible to have distinct ACM timeout values for client connections and administrative client connections. As Bernard pointed out, Ice can scale to a very large number of connections so it shouldn't be an issue if your client connections to IceGrid remain open for few minutes (it might even be beneficial if your clients need to make several invocations to IceGrid to retrieve endpoints).

    Cheers,
    Benoit.

    Thank you, Benoit.

    Regards, Alexander.
Sign In or Register to comment.