Searching object adapter for servants

[ctennis]

This is probably too late for 3.3, but one thing that would be handy would be to be able to get a list of servants from an object adapter based on a passed in string category. Something like:

Ice::ObjectSeq findByCategory(string category);

(and probably one for specific facets as well).

This can be incredibly handy because then you don't have to maintain a list outside of the adapter of all of the servants in it if you want to be able to iterate over that list for some reason (maybe you need to get the name of each of the servants, for example).

[michi]

We could add an operation that returns a subset (or all) of the map. The application would have to make sure though that, by the time it gets around to using the result, the result still makes sense because the ASM may have been modified by other threads in the mean time.

Could you explain a little more about what you are trying to do? Maybe there is another way to achieve what you need. (I'm not opposed to adding such an operation to the ASM per se, but I want to be sure that there is no reasonable alternative for achieving the same thing in the application.)

Cheers,

Michi.

[ctennis]

I wrote a long winded explanation to this, but when I got to the end of it I came to the conclusion that everything I want/need to do can be implemented via a little smart logic with servant locators. I can just create a new subclass of the servant locator that implements the logic I want, then subclass it again into my actual locators that will handle the specific categories.

I think the main "issue" stems to the fact that there's no way to get a servant back from an object adapter unless you explicitly know its whole identity. There are times when I don't want to have to keep track of individual object identities, but instead throw a bunch of servants into a single "category" and be able to get back a list of those objects later so I can iterate over them...perhaps in a background thread that performs an "update" of their internal data.

Right now the only way to do this is to create my own map that contains the objects (either alongside an object adapter's ASM or inside of a servant locator). The first is a bit redundant and prone to some error, especially if you're adding or removing servants throughout the code as you have to make sure you're also adding/removing them from your secondary map. The latter is a better way of going about it, but then means you lose all of the advantages of having the ASM keeping track of your servants for you, and makes the program a bit more complex.

So I think my "feature request" is more to save from having to go the full blown route of implementing servant locators just to be able to more easily consider servants at the category level instead of the individual object level.

[michi]

Hi Caleb,

yes, I understand where you are coming from. We'll consider adding something like this (but no promises!)

Cheers,

Michi.

[paolo]

That feature would be very useful also for me thx

[joshmoore]

+1 Though I haven't tried the servant locator solution, I do often have an accompanying hash map from id to servant which has to been kept in sync with the ASM. If there are no locking issues, etc., it seems like it would be helpful. And since even when just acquiring a single servant from the ASM, there is a race condition, I'd be for it. Thanks, ~J.

[michi]

It seems you can do what you want by simply using a default servant that implements its own hash map. That way, the ASM is empty and all the identity-to-servant mappings are taken care of by your default servant. Now you can iterate over the map (or perform whatever other operation you need) to your heart's content.

With this approach, any concurrency issues are now the responsibility of your implementation. That's as it should be, seeing that you know a lot more about concurrency of your application than the Ice run time does.

So, overall, it seems to me that it is better for you to implement a default servant than it would be for the Ice run time to provide an API that risks returning stale information to the application.

Cheers,

Michi.

[joshmoore]

For others, see 32.9.2 Default servants which I found while wondering if there wouldn't need to be several default servants. And there would. One per type. And (32.8 Default servants) the category whould need to be the type? Will this work with glacier then where the category must be the session id?

If the combination is ok, then like the servant locator solution, it sounds very workable, but I still think for very simple use cases, find/search methods by type/category on the object adapter would be handy even if it's the consumers responsibility to check the "liveness" of any servant. (Typically, I want to find all servants with a glacier session as category in order to remove it.)

Thanks, Michi.
~Josh.

[michi]

And (32.8 Default servants) the category whould need to be the type? Will this work with glacier then where the category must be the session id?

This is an issue only if:

• a client provides callback objects to a server
  
• the callback objects have different Slice types
  
• the client implements the callback objects with a default servant or servant locator

In this case, the category of the object identity is used by Glacier2 to demultiplex callbacks from the server to the clients and you have to either mangle the object type into the name member, or implement the client's callback objects using the usual ASM approach.

Cheers,

Michi.