Arbitrary (UUID) Identity and findObjectById

kishore

First a little bit of a background on what I am attempting to do and why.
Sorry for the verbosity:

So, I got the IceGrid to work with servers getting launched on demand etc.
However our use case is a variant on the typical client server use case. Typically servers are running endlessly serving multiple clients. In our case multiple servers get launched to serve a single client. Each server runs under
a very specific environment, with numerous variables. Makes reuse of the server inherently complicated. Plus, there is a risk on contamination from previous runs, and also debugging nightmares. So pretty much the servers
have to be started and killed once they are done serving a client. It seemed
that IceGrid paradigm didn't really suit our needs.

In order to reap the other benefits of IceGrid, we decided to look into
a sort of a two layer architecture on the server side. In essence, I have programs these "Launcher" programs that then fork off the real servers with specific environment variables set. The Launchers can run endlessly, as they are really simple, and almost application agnostic, whose sole job is to start off programs, with specific environments. We don't have to launch these Launchers as icegridnode can start them on demand, or restart them if they fail. Once a server is launched, it needs to expose its objects to the client that started it.

I am trying to make my client use a specific Server object of the many server objects that may be running. Each client creates a unique identifier, and the servers are launched with that code. I want all the server objects to use
that code as their identities so I can use the registry locator to find them.
I am having some trouble locating those objects in the registry.

In my client I am trying to use findObjectById to find a proxy to a servant object. The server starts and adds an object to its adapter with an arbitrary
assigned to the object.

On the server side:
std::string something="0123456789";
Ice::Identity id = communicator()->stringToIdentity(something);
Ice::ObjectPtr object = new MyObjectImpl();
adapter->add(object, id);
adapter->activate();
communicator()->waitForShutdown();

On the client side:
IceGrid::QueryPrx query = IceGrid::QueryPrx::checkedCast(proxy);
Ice::Identity* serverId = new Ice::Identity();
std::string something="0123456789";
serverId->name =something;

Ice::ObjectPrx serverObject = query->findObjectById(*serverId);
if (!serverObject)
std::cerr << "Invalid serverObject Proxy";


Obviously it is not working. The unique ids are dynamically generated so I
can't specify them in the xml descriptor file. Which is why the server does not even get launched "on demand" with this approach. It seems for a server to get launched one of its objects must be used, but I am trying to find an object to use in the the first place, so there is a bit of catch 22. But even if I manually launch the servers prior to running the client, I still don't find a valid proxy. Is this approach flawed to begin with? I can find the objects by
type, but the type is static, and hence was added with the xml descriptor file.
Am I missing a step? Can a program that wasn't launched through the icegrid still use the registry? As in my case, the "servers" and started by the "launchers"...


Any thoughts? If this approach can't work, my idea is to communicate the stringified proxies back to the client from the servers. Also curious to
hear any comments on the entire approach.

thanks
Kishore

michi

Objects that servers create don't magically appear in the registry. Instead, they need to be added explicitly, via an XML descriptor, with the admin tool, or programmatically.

You could do this by having your back-end server register a well-known object with the registry when it comes up by calling addObject and on the IceGrid::Admin interface. Before the server shuts down, it needs to call removeObject(), otherwise these well-known objects will accumulate in the database. (See the section on well-known objects in the IceGrid chapter of the manual for more detail.)

But, seeing that you have a front-end server already that spawns the back-end servers, why not have the front-end server return a proxy to the back-end it just created to the client? That way, you don't have the issue of potentially lost registrations for well-known objects in IceGrid if servers crash. In effect, this approach would make the front-end server a factory for back-end servers, and the factory operation would return the proxy to an object in the back-end server.

Cheers,

Michi.

kishore

Thanks Michi, for the prompt response. It makes sense. I can see how registry database can get immensely huge over time due to uncleaned object ids.

Not a huge issue since the front end servers can also cleanup the
ids from the registry even if the backend server dies without cleanup,
and so can the client. However there seem to be little or no advantage to using the registry in this case, but potentially seems a little more scalable
and keeps the proxy management code outside the server.

Kishore

bernard

Hi Kishore,

kishore wrote: »

In our case multiple servers get launched to serve a single client. Each server runs under
a very specific environment, with numerous variables. Makes reuse of the server inherently complicated. Plus, there is a risk on contamination from previous runs, and also debugging nightmares. So pretty much the servers
have to be started and killed once they are done serving a client.

IceGrid actually includes a number of features just for this situation: sessions, and object allocation. Please refer to "38.10 Sessions" in the Ice manual:
http://www.zeroc.com/doc/Ice-3.2.0/manual/IceGrid.39.10.html

I'd also recommend to read Matthew Newhook's articles in issues 16, 17 and 18 of our newsletter ... start with "IceGrid Sessions and Resource Allocation" in issue 16.

Best regards,
Bernard