Archived

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

about icegridregistry

I've read the IceGrid section of Ice 3.1 document, IceGrid really has an excellent performance in node administration and load balancing,
here is a question: how to solve the halt of system when icegirdregistry breaks down, if the machine in which icegridregistry is running is shutted down, we have to restart it manually.
If there is a standby server to duplicate the registry, it is possible to transfer new clients to connect to the standby server if icegridregistry has problem in accessing.
this problem might have been considered. If you have other methods to solve this, please reply to this post.

thanks~

Comments

  • benoit
    benoit Rennes, France
    At this time, the IceGrid registry doesn't support replication, you can only run one instance of the registry. Implementing replication for the registry is on our TODO list!

    Cheers,
    Benoit.
  • And when will the replication of the IceGrid registry add to Ice?

    Thank you. for our scada system strongly rely on the replication.
  • marc
    marc Florida
    I'm sorry but we don't have a release date for this feature.
  • Shame

    I was about to ask the same question.

    The registry is a single point of failure, it seems, which is a Very Bad Thing for any kind of mission critical app.

    At the moment, because of this, we are thinking of not using IceGrid, but rather using a list of named (well known) servers or similar. We don't really need the indirection and load balancing features of icegrid, so this may be a more viable solution. We could then put this list into a more robust database than the ice registry.

    I am curious as to how best to do this sort of approach.
    We:
    - Have a more or less fixed list of servers, each running a small number of servants.
    - The number of servants per box doesn't change (1 per processor).

    If we want to avoid using the registry, is a database of well-known objects a reasonable solution here? Any comments would be welcome.

    Thanks,

    Tom
  • benoit
    benoit Rennes, France
    Hi Tom,

    Before we answer your questions, could you please set your signature? You'll find details on how to set it [thread=1697]here[/thread].

    Thanks,

    Benoit.
  • Is this better?

    Hopefully I should have a more informative sig now...
  • Actually for "well known objects" read "direct proxies"

    I got my terminology confused above.

    As I understand it, well known objects relate to ice grid, so we couldn't use those unless we use the registry.

    But we could use direct proxies for all our servers, and maintain a replicated DB of such direct proxies.
  • benoit
    benoit Rennes, France
    Hi Tom,

    Replication of the IceGrid registry is one of the most requested feature for IceGrid and it's at the top of our priority list. We just started working on it so this something you can expect to see in upcoming Ice releases.

    Otherwise, you can use whatever mechanism you find the most convenient to replicate the information which is needed to access your servers. Storing the proxies for your servers in a database that supports replication should be fine. This means however that you introduce an additional dependency on the database for your clients and servers.

    Cheers,
    Benoit.
  • benoit
    benoit Rennes, France
    tomcwalker wrote:
    But we could use direct proxies for all our servers, and maintain a replicated DB of such direct proxies.

    Right. If you use direct proxies, you'll have to make sure the servers are either listening on a fixed TCP/IP port or if they don't, you'll have to update the direct proxies each time a server is restarted (because the TCP/IP port might have changed.)

    Another option would be to develop another locator implementation which feets your needs and rely on your replicated database (the locator interfaces used by the Ice runtime are defined in slice/Ice/Locator.ice). This way, you could use well-known/indirect proxies in your clients. This might be more complicated to implement but this could end up being a better solution if you don't want to introduce a dependency on the database in all the components of your application.

    Of course, you can also just wait for the IceGrid registry to support replication :)

    Cheers,
    Benoit.
  • Thanks

    Thanks for the very helpful replies Benoit. They really helped clarify the options.

    For our application, we already have a couple of databases which are industrial strength, and already used by servers. So the extra dependency isn't really an issue, and we'll thus probably go down the direct proxy route initially.

    We can then migrate to ICEGRID when the registry supports replication.

    Thanks again!