FT — FT-FTF Issue: Request more powerful property management

There are 3 problems w.r.t. property management which I will list
together since a solution could/should address all of them. I will
send a proposed solution in another message.

---------------------------------------------------------------

• • Problem A **

For sequence-valued properties, there should be a way to add or remove
one or more elements from a sequence value without having to resort to
using more than one method call.

Notes:

Currently, one has to 'get' the current sequence value, modify it, and
then 'set' the sequence value. This results in a nasty race
condition: it is not safe to have independent threads of control doing
get-set combinations.

A simple solution is to have new methods for element update. A
complex solution is to allow any number of updates, including property
set, element addition, element removal, for default and type and
dynamic, all to be grouped and sent to the manager in one
property_update request. For example, one might want to group the
removal of a property P from type T and the addition of property P as
a default property.

---------------------------------------------------------------

• • Problem B **

The property management interface has insufficient power.

Notes:

One can query or update over a single type or a single object group,
but not over a set of types or a set of object groups. Further, one
cannot:

• get a list of types that have
  + at least 1 property defined;
  + specific propert[y|ies] defined;
  + at least 1 factory at specific location[s];
  [ or modify properties for the specified types ]

• get a list of existing object groups that have
  + specific propert[y|ies] defined;
  + specific type[s];
  + an active replica at specific location[s];
  [ or modify properties for the specified object groups ]

• get a list of active replicas that have
  + specific type[s];
  + specific location[s];
  [ or modify properties for the specified replicas ]

• get a list of locations that have
  + at least 1 property defined;
  + specific propert[y|ies] defined;
  + at least 1 active replica;
  + an active replica for specific object group[s];
  + an active replica of specific type[s];
  [ or modify properties for the specified locations]

• other query/update cases that should be supported?

---------------------------------------------------------------

• • Problem C **

The property management interface does not sufficiently distinguish
between high-level FT QoS properties used to manage entire object
groups and low-level object construction properties used to
select factories and create individual replicas.

Notes:

High-level QoS properties change infrequently, and never differ across
replicas. Low-level construction properties change more frequently as
factories are created/destroyed/lost, and they do differ across
locations/replicas (different factories, different criteria).

In each case, one must distinguish between properties for an existing
object group and properties to be used for future object groups. Even
for replica construction properties, one should be able to assign a
different set of locations/factories to be used for new replica
creation for existing object group[s] and for future object groups.

Currently, low-level properties are buried in a single value that is
stored with a single property (FactoryInfos), either for a specific
type or for a specific object group. This makes it very hard to do
lookup or modification of these properties by location or by the pair
type x location or object group x location. To replace an Info for a
single location one must replace the entire Infos sequence. Even with
the ability to add/remove a member of a sequence, to replace either
the factory or the criteria within a given Info one would have to
remove the current Info and replace it with a new Info, where the Info
would need to contain a copy of the part(s) that are not to be
modified together with the modified part.

BTW I am leaning towards splitting the PropertyManager into a
GroupQoSManager and a FactoryManager, but other approaches are
possible. One argument for the split is that it seems to make sense
for a FactoryManager to monitor the liveness of registered factories
and to provide logic for selecting an appropriate factory and
associated criteria for construction of a new replica for a given
group or type. In contrast, it does not make sense for a generic
property manager to do monitoring (or to know anything about the
values stored in properties).