Registry and Querying

moatas

I have been trying to write an example of querying for objects based on type. I have an icepackregistry running allowing dynamic registration. I can successfully register servers with an AdapterId, and have clients connect via the adapterid using indirect binding.

But when I do the following:

query = QueryPrxHelper.checkedCast(communicator.stringToProxy("IcePack/Query"));

query object is good

but

query.findObjectByType("::Ice::Object");

always throws the following:

query = IcePack.QueryPrxHelper@b7d3ed4a
IcePack.ObjectNotExistException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at java.lang.Class.newInstance0(Class.java:308)
at java.lang.Class.newInstance(Class.java:261)
at IceInternal.BasicStream$DynamicUserExceptionFactory.createAndThrow(BasicStream.java:1770)
at IceInternal.BasicStream.throwException(BasicStream.java:1404)
at IcePack._QueryDelM.findObjectByType(_QueryDelM.java:122)
at IcePack.QueryPrxHelper.findObjectByType(QueryPrxHelper.java:99)
at IcePack.QueryPrxHelper.findObjectByType(QueryPrxHelper.java:84)
at playground.ServiceLookup.getServiceByType(ServiceLookup.java:51)
at playground.ServiceLookup.main(ServiceLookup.java:56)

I switched gears and deployed the IcePack demo to an IcePack node. Contacting this registry actually works.

So my question is this. To successfully query a registry, does the service have to be published to an Icepack node? Can you not just have a registry running, have the services add themselves othe registry, then use a client to lookup the service by type?

Thanks!

James Birchfield

vsonnathi

Hi,

The type here refers to the type in the Identity (id, type) and not that of the Object.

thanks,
--Venkat.

moatas

Understood. The code works fine after I use the admin tool to either deploy an application, or add an object with the appropriate endpoints. So this leads me to believe that the query functionality only works when things have been deployed using the admin interface, and services that register adapterids do not automatically qualify.

Birch

mes

Welcome to the forum!

The findObjectById and findObjectByType query operations can only be used to find objects that were explicitly registered with the registry. This usually occurs when you've deployed an application that advertises well-known objects, but it could also be done by calling addObject directly on the IcePack::Admin interface.

In addition, the findObjectByType operation is not polymporphic. In other words, passing "::Ice::Object" as the type would only return an object that was explicitly registered with that type id. IcePack does not ask each object whether it implements the given id.

Take care,
- Mark

moatas

Thanks. That is what I needed to know.

Given that, how would I go about doing this in a programmatic way if I did not want to deploy the service as an IcePack application like the demo?

Taking the hello demo into acount, can you show how this would get deployed?

Ice.Object hello = new HelloI();
Ice.Identity id = Ice.Util.stringToIdentity("hello");
adapter.add(hello, id);
adapter.activate();

I fI get an AdminPrx handle, I cannot just do admin.addObject(hello) because it is not an ObjectPrx. Do you happen to have an example of this type of functionality? Or am I going about it all wrong?

Thanks!

Followup: I did get the admin interface to work if i did this:

admin.addObject(communicator.stringToProxy("hello:tcp -h 192.168.0.200 -p 11000"));

after I call activate on the adapter that created the object.

mes

The call to ObjectAdapter::add returns a proxy, so that is the easiest way to get one. Your example would change like this:

IcePack.AdminPrx adminPrx = ...
Ice.Object hello = new HelloI();
Ice.Identity id = Ice.Util.stringToIdentity("hello");
Ice.ObjectPrx proxy = adapter.add(hello, id);
adapter.activate();
adminPrx.addObject(proxy);

- Mark

moatas

Doh! Was just about to post that discovery!!! Thanks for the help.

Now to the next phase of this problem. I am trying to determine the best approach for scaling up the number of objects available. If I write a number adding server and want to deploy 10 of them to different machines, how do I register them?

My hope was I would register them all with he same adapter info. If that were the case, then I was hoping the registry would return me the next available one in a round robin type fashion. But I suspect i would get an ObjectExistsException on the second one. Would I just assign unique id to them to keep them from clashing? I get this working initially by doing this.

Can you provide any insight on the best way to acheive this scenario?

Thanks!

Birch

mes

IcePack doesn't currently support replication, but this is something we're considering for a future release.

If you want a randomized result, you could register several objects with the same type (each with unique ids) and then call Admin::findObjectByType. If IcePack finds multiple matches, it returns a randomly-selected one.

Hope that helps,
- Mark

moatas

This is what i will do for now.

Thanks for all he help!

Birch