Archived

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

help about rewrite my own ObjectAdaperI

I plan to write my own locator server, this is my plan:

1. Write my own ObjectAdapterI which inherited from Ice.ObjectAdapterI and reimplement the following two methods:
  1)activate()
    Start a seperate thread, which periodly(such as 5 minutes) register/update object information to my locator server.
    
  2)deactivate()
    Unregister from my locator server and then stop the thread.

2. Write my own locator server, which has the following behavior:
  1)Set a lifetime for every register item. If the lifetime eclapsed and no new update reaches, then just clean the register item.

With this new locator server instead of IceGrid, I can no longer worry about IceGrid's complicated configuration. When some of my servers crash, I no longer have to worry about the garbage registry infomation in IceGrid.


However, I find Ice.ObjectAdapterI is a final class and some of its methods and member variables are private. So if I want to write my own ObjectAdapterI, I have to copy most of Ice.ObjectAdapterI's code in my class. This is very disappointed!

Furthermore, I find that most of Ice classes are designed in the same way. Is there any reason for this ?

Thank you.

Comments

  • ObjectAdapterI is internal code, and not intended to be used or extended by application code. It might change without notice. The same applies for all other Ice internal classes.
  • matthew
    matthew NL, Canada
    Not knowing exactly what you want to do its hard to give very comprehensive reply but I think you'd be better off writing a wrapper around the existing OA instead and having your users use that instead of trying to implement the OA interface.

    You probably realize this but this solution doesn't scale very well -- I hope you won't have 1,000,000 objects on the same OA :) There is no need to register all objects associated with an OA -- if you know the location of the OA, then you also know the locations of each of these objects.
  • benoit
    benoit Rennes, France
    Hi,

    You could also consider writing a default servant locator instead of trying to extend the object adapter. You would register servants for objects which need to be accessible through your Ice::Locator implementation with your servant locator instead of using the object adapter ASM (active servant map).

    Btw, it would be interested to know what you find complicated with the IceGrid configuration (did you check out Michi's article in the last newsletter? "Teach Yourself IceGrid in 10 Minutes" :)) and why you need all the objects registered with your server object adapters to be accessible through the locator interface. In general, you should only need few well-known objects (factories, managers, etc) and these well-known objects are then used by clients to locate other objects specific to the application.

    Cheers,
    Benoit.
  • Thank you all. Sorry for my poor English:)

    1.
    This is the current behavior of Ice.ObjectAdapterI:
    1)When it is activated, it registers its ObjectAdapterId to a locator service(Now, it is IceGrid registry).
    2)When it is not activated , it unregister its ObjectAdapterId from the locator service.
    

    This behavior is OK in most of time. However, in practice, if:
    1)The server crashed.
    2)The server is killed (kill -9) by one system administrator
    3)...
    
    Then some rubbish register items will stay in IceGrid registry until you manually remove them.


    2.
    This is what I want to do:
    1)Reimplement a locator service which gives a lifetime(such as 5 minutes) for each register items. When the lifetime eclapses and the register itme have not update their lifetime, the new locator service just deletes them.

    2)So I have to change Ice.ObjectAdapterI's behavior a little. I hope that the ObjectAdapter can update its register infomation periodly(such as 5 minutes).
    Furthermore, during the update, I want to take more infomation such as:
        a)How many requests each object/servant has processed during the last period.
        b)How much network flow each ObjectAdapter has processed.
        c)The host performance(I/O,CPU,Memory) of the ObjectAdapter
        d)Of course, the register can both be object-based andObjectAdapter-based.
        e)...
    
    Then my new locator service can implement a more precise load balance(such as request-based load balance).

    However, though I can reimplement a new locator service, it is very difficult to change the behavior of Locator client because its code is integrated in Ice.ObjectAdapterI. If I can not do the latter, the former is useless.
  • Actuallly, whether to register objects or ObjectAdapters is not so important for me.

    The most interesting feature that I what to get is that location service can automatically remove invalid register items instead of manually removing them when some servers exit abnormally. Based on my experience, this feature is very powerful and useful if you have more than 100 servers and you have to stop and start some of the servers frequently. If IceGrid can do this, then I can just start IceGrid and no longer worry about it again even if some servers are killed by my system administrator(kill -9) or some servers crash for some application-level bugs or some other reasons(the machine/network error).

    Anyway, in my view, IceGrid is an Ice service, so as Ice manual says:
    The services are implemented as Ice servers to which your application 
    acts as a client. None of the services use Ice-internal features that 
    are hidden from application developers so, in theory, you could 
    develop equivalent services yourself. 
    

    I think it would be better that application developers can easily reimplement both the server side and the client side of location service(Locator.ice).
  • Which client side are you exactly referring to? The Ice core has no inherent knowledge of IceGrid. It only knows the locator interface. For example, test/Ice/location uses Locator.ice, but it does not use IceGrid. Instead, it uses a simple locator included in this test.
  • marc wrote:
    Which client side are you exactly referring to? The Ice core has no inherent knowledge of IceGrid. It only knows the locator interface. ...
    I refer to the Ice core. I know that the Ice core has no inherent knowledge of IceGrid and that it just knows the locator interface. I mean that it would be better if Ice core can allow 3rd-party code to change its client-side locator behavior (client-side router is the same). If so, then 3rd-party can downcast to his own Locator/Router proxy and get more precise control of locator/router behavior.

    Some codes can explain what I mean:

    1.MyGrid.ice
    #include <Ice/Locator.ice>
    
    module MyGrid
    {
    struct LoadBalanceInfo
    {
    //The eclapsed time since last registry update
    long		interval;
    
    //How many request are processed(or during processing) since last update
    long		requests;
    
    //How much networkFlow are processed since last update
    long		networkFlow;
    
    //Other information about load balance
    //...
    };
    
    interface LocatorRegistry extends Ice::LocatorRegistry
    {
        void setAdapterDirectProxy2(string uuid, string id, Object* proxy, LoadBalanceInfo info);
    };
    }
    

    2.MyObjectAdapter.java
    class MyObjectAdapter [B][COLOR="red"]extends Ice.ObjectAdapterI[/COLOR][/B]{
    MyObjectAdapter(...)
    {
    	//generate a  uuid for each ObjectAdapter
    	uuid = ...;
    }
    
    void activate(...)
    {
    //1.the same as Ice.ObjectAdapterI's activate()
    
    //2.start a thread which periodly call updateLocatorRegistry()
    }
    
    void activate(...)
    {
    //1.stop the thread which periodly call updateLocatorRegistry()
    
    //2.the same as Ice.ObjectAdapterI's deactivate()
    }
    
    
    void updateLocatorRegistry(...)
    {
    //1.downcast to get a MyGrid.LocatorRegistryPrx
    Ice.LocatorRegistryPrx defaultLocatorRegistry = ...;	
    MyGrid.LocatorRegistryPrx locatorRegistry = MyGrid.LocatorRegistryPrxHelper.checkedCast(locatorRegistry);
    
    [COLOR="Red"][B]//2.collect load balance infomation
    // ...[/B][/COLOR]
    
    //3.update locator registry
    locatorRegistry.setAdapterDirectProxy2(...);
    }
    
    Because the Ice core does not allow 3rd party to change its client-side locator behavior, the two red parts in MyObjectAdapter.java are wrong.
  • benoit
    benoit Rennes, France
    Hi,

    Why do you absolutely want to specialize the object adapter implementation? As you discovered it hasn't been designed to be extended this way :).

    You should either write a default servant locator or wrap the object adapter with your own class as Matthew suggested (your class could implement the Ice::ObjectAdapater local interface and delegate to the Ice object adapter for example).

    Also, note that if you're using IceGrid nodes to manage your servers, you don't have all the issues you're mentioning, e.g.: endpoints of crashed servers are cleared automatically from the registry when the node detects that the server crashed. You can also use replica groups which provide some load balancing based on the load of the machine.

    Cheers,
    Benoit.
  • benoit wrote:
    Hi,
    You should either write a default servant locator or wrap the object adapter with your own class as Matthew suggested (your class could implement the Ice::ObjectAdapater local interface and delegate to the Ice object adapter for example).
    Thank you, benoit and Matthew. I have not understood what Matthew means and now I catch it. I can do what I want in the default servant locator. This is a very wonderful solution.
    benoit wrote:
    Hi,
    Also, note that if you're using IceGrid nodes to manage your servers, you don't have all the issues you're mentioning, e.g.: endpoints of crashed servers are cleared automatically from the registry when the node detects that the server crashed.

    Really? Maybe I should read again the IceGrid part in Ice manual:)