Home Help Center

Dynamic registration of allocatable objects

bssbss Member Bennett ScottOrganization: RaytheonProject: Distributed Automated Test management system
In my first Ice application, I'm putting together an Ice application where each of the servers on multiple hosts will be dedicated to an individual test station. Each one of these test stations may be on or offline at any time. The clients select one of the test stations that is online based on user input.

A lot came up troublefree - the distributed calls across multiple languages and operating systems, using IceGrid to dynamically register/unregister the servers as they come online, and querying the registry to get the set of servers.

The final feature I would like to get running is the allocation capability of IceGrid to restrict any one server to servicing one client during the duration of the testing sequences. First attempt refused to allocate (that is, to even find) the servers. I think that this is because the well-known objects, registered by AddObject calls that I have been using so far are not allocatable objects. I think that I would need to use AddApplication with appropriate descriptors to set the allocatable properties. Since the servers dynamically register themselves, the XML solution is not preferred.

My problem is that the documentation is extremely sketchy in this area. It looks like I need to supply parameter/value pairs that probably correspond to the XML, but as to the parameter strings, that would be a guess right now.

Does anyone have any info or examples (especially examples)?

Thanks.

Comments

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

    From your description, it sounds like you're not deploying your servers with IceGrid nodes (as described here) but instead just dynamically register them with the registry thanks to the IceGrid registry dynamic registration feature (as described here). You're also using the IceGrid::Admin interface to add/remove well known objects when your servers start and stop. Is this correct?

    If this is the case, I'm afraid you won't be able to use the IceGrid allocation feature. Along with other features (advanced replication, server monitoring, patching, etc), IceGrid object allocation is only available to servers deployed on IceGrid nodes. Is there any reason why you choose not to deploy your server with IceGrid nodes?

    Note that you don't necessarily have to use XML descriptors to deploy servers on IceGrid nodes. You can also register the servers programatically (with the IceGrid::Admin interface) or using the IceGrid administrative GUI.

    Cheers,
    Benoit.
  • bssbss Member Bennett ScottOrganization: RaytheonProject: Distributed Automated Test management system
    You are correct, that is what I'm doing.

    I chose to not deploy the servers via a node for two reasons:

    1. To minimize system components. This is the first time I've used (or seen) Ice, and wanted to keep the components and learning curve involved to a minimum. This is only a small part of the entire system, and I have a lot of other pieces to tackle. Three languages, three IDEs, two O/S's, etc......
    (Of course, the rest of the Ice system came up easily enough - kudos to your team).

    2. I need some mechanism to let the users know which test sets (each being serviced by a server) are available (online). Right now, that is simply done by having the server manually started, which registers it in the registry, which makes it visible via queries. I suppose I can do the same with manually starting a node when a testset is available.

    It may come down to the following question - is there a way to determine which servers have been allocated and which servers (or nodes) are unallocated through the registry APIs, other than trying to allocate it and getting an exception? I still would like a mechanism indicating to the users not only which testsets are online, but which ones are not busy (not allocated). This system requires that the user be able to select execution of tests on a specific (chosen) system - not all testsets are created equal. If I can't do this, I may need to create a small allocation server to handle that task (not a difficult task, but just another one).

    Thanks.
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    bss wrote: »
    2. I need some mechanism to let the users know which test sets (each being serviced by a server) are available (online). Right now, that is simply done by having the server manually started, which registers it in the registry, which makes it visible via queries. I suppose I can do the same with manually starting a node when a testset is available.

    Right, you could just start the node and the node would take care of starting the server deployed with the deployment mechanism. This allows you to eventually deploy more servers per node and also to have better control on the servers (if a testsets server crashes, it can be re-started automatically by the IceGrid node, if it hangs you can kill it remotely, etc).
    It may come down to the following question - is there a way to determine which servers have been allocated and which servers (or nodes) are unallocated through the registry APIs, other than trying to allocate it and getting an exception? I still would like a mechanism indicating to the users not only which testsets are online, but which ones are not busy (not allocated). This system requires that the user be able to select execution of tests on a specific (chosen) system - not all testsets are created equal. If I can't do this, I may need to create a small allocation server to handle that task (not a difficult task, but just another one).

    Thanks.

    No there's currently no way to figure out which objects are allocated or not. You might indeed be better off implementing your own service to handle the allocation of your test sets. Eventually this service could use the IceGrid allocation mechanism under the hood if it needs some of its features (such as the session activation mode for example).

    Cheers,
    Benoit.
Sign In or Register to comment.