question about replicated objects

[istvan]

Dear Ice experts,

I've experimenting with replicated objects and the chat server code that appeared in Connection. What I tried to achieve is to replicate the UserManager object. Here is what I did in the IceGrid descriptor:

  <replica-group id="UserManagers">
    <load-balancing type="adaptive" load-sample="5" n-replicas="2"/>
    <object identity="UserManager" type="::Chat::UserManager"/>
  </replica-group>

After depoyment there is a UserManager available on two nodes.
Now, when I want to add a new User using the add() method I would like to add it on all nodes where UserManager is deployed to keep them in synch. I thought that I could use the IceGrid::Query interface and find all objects of type ::Chat::UserManager with findAllObjectsByType() but that call returns only one Proxy most probably using the load balancing strategy configured in the IceGrid descriptor.

So, on one hand it is very convenient to have the replicated objects for some operations like finding a user because then we don't care which UserManager object will handle the request but on the other hand for updating the UserManager replicated objects seems to be a problem because it is not possible to access the replicas separately.

Maybe this is not a problem and only due to my lack of knowledge but I would appreciate any advice on how to handle such case.

Thanks,
Istvan

[matthew]

While this is a possible approach for replicating the user manager I don't think it is the best approach. As you say you would need to add all of the users to each user manager. Furthermore you would have to keep all of the users in sync somehow. That is quite a difficult problem.

I recommend reading issue 10 of the newsletter for an article on an alternative approach to solving this problem.

[istvan]

Thanks for your reply Matthew,

unfortunately I think the UserRegistry solution is only displacing the problem I was trying to solve: avoiding single points of failure. If I replicate the registry I'll have the same problem I have with the replicated UserManager, isn't it?

[matthew]

Replicating the user registry is a much simpler task than replicating the user manager. If a single user manager fails some number of your users will lose the ability to login (until you fix whatever problem caused the failure). If this is acceptable then I would recommend the solution outlined in the article. If this is not acceptable, then you need to do full replication as you intend ... but this is a far from trivial problem.

I would also not recommend peer replication, but rather some sort of master-slave system. In this type of replication ONLY the master is always updated by the client. The master then sends updates to the slaves. If there is a failure of the slave, no problem -- the client doesn't talk with it and the master can re-sync when it comes back up. If there is a failure of the master the client can then fallback on the slave.

In this case then you have some choices -- for example, the slave now becomes the master and the master when it comes back becomes the slave. Another choice is that the slave does not accept any data updates, but only provides read-only access to its data.

[istvan]

Thank you for all your comments Matthew.
I'll experiment with the user registry to get a better feeling of what can be done before going for the more complicated solutions.