Home Help Center

icegrid and server-instances

area51area51 Member Wout BettensOrganization: Key Technology (Visys) - BelgiumProject: Machine session management
Hi,

My intention is to have (multiple) clients get an unlimited (or undefined) number of proxies to the same service (allocated by type).

I'm trying to configure this using icegrid with a server-template.

As described in demo/IceGrid/allocate/application-multiple.xml, an index property is needed. But isn't this preventing me from the 'unlimited' number of instances?

Secondly, I would like to have these services run as being the user which was authenticated through the icegrid session (so, session activated), but then my clients are not getting a suitable endpoint for my service.

How should I correctly configure my xml? I guess I'm a little confused at this moment ;) Maybe I shouldn't use a template at all for this purpose?
(system is debian linux, using Ice-3.2.1)

Thanks in advance

Comments

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

    I recommend to upgrade to Ice 3.3.1, we usually only provide free support on the forums for the latest version of Ice.

    If I understand it correctly, you want each client to invoke on a dedicated service process? Why do you need to allow an unlimited number of service processes? I assume the number of clients is limited so can't you simply deploy as many servers as there might be clients?

    To start a server with a specified user ID you need to set the "user" attribute of the server XML element with the value of the session identifier, for example:
          <server id="SessionServer" exe="./server" activation="session" user="${session.id}">
    

    For this to work, the node will need to run as the super user.

    Cheers,
    Benoit.
  • area51area51 Member Wout BettensOrganization: Key Technology (Visys) - BelgiumProject: Machine session management
    Thanks for the quick reply!

    The reason I'd like an unlimited number of instances is the following:

    One client may need about 100 proxies to the same kind of service process, each representing a unique element that is being controlled on the server. This number might still grow to 200 or even more.
    Let's say we would limit the number of clients to 5. That would still get me to define 1000 server-instance entries in the xml.

    We could bundle all these proxies, so using 1 service per client. But then the clients need to do all the work to dispatch to the correct destination in their application. Performance is an issue here.

    (I'm planning on upgrading to the latest release asap)
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    If I understand it correctly, your host would need to spawn 5 * 200 processes to handle 5 clients because each server only hosts a single Ice object to provide access to a service instance.

    Why not allowing a server to host multiple Ice objects (providing access to as many instances of your service) and use a one-process per client model instead? This would require only a total of 5 processes.

    Cheers,
    Benoit.
  • area51area51 Member Wout BettensOrganization: Key Technology (Visys) - BelgiumProject: Machine session management
    That sounds like a much better solution.
    It needs a complete redesign from my side, spawning all those processes is a very bad idea anyway.... ;-)

    Thank you very much
  • area51area51 Member Wout BettensOrganization: Key Technology (Visys) - BelgiumProject: Machine session management
    One more thing...

    You mentioned to set user="${session.id}" for the server xml element, but what do you mean by running the node as root (or super user)?
    Where and how do you specify which user will be used for the node itself?

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

    You need to start the IceGrid node under the "root" account. On Linux, this is typically done by start the IceGrid node from an init.d script. We provide such scripts with our SuSE and Red Hat RPMs. I'm not sure whether or not such scripts are provided with the Debian packages however (we don't maintain these packages).

    Cheers,
    Benoit.
  • area51area51 Member Wout BettensOrganization: Key Technology (Visys) - BelgiumProject: Machine session management
    Thanks, that's what I thought, we are using the init.d scripts and it's already running as root.

    Ice 3.2.1 is provided in the debian stable repository, but for the latest release, I need to grab it from debian testing. That's why we didn't upgrade yet.
  • area51area51 Member Wout BettensOrganization: Key Technology (Visys) - BelgiumProject: Machine session management
    Hi,

    I noticed when spawning processes with session activation, the log file must allow write permissions for the session user. Although, the IceGrid node is running as root.
    <server id="SessionServer" exe="./server" activation="session" user="${session.id}">
       <log path="SessionServer"/>
    </server>
    

    When the log file is write protected, the service won't start. Is there any way to override this behavior?
    (In the mean time, I've upgraded to the current release)

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

    It's not clear to me from your description what exactly is the error or what you expected instead. It's your responsability to ensure that the log files or any other files opened by the service are read/write accessible to the process when the process is run under a specific user ID.

    Cheers,
    Benoit.
Sign In or Register to comment.