Local entity/attribute overlapping with registration unnoticely bypass Context Provider forwarding logic

[dmoranj]

Consider the following scenario with the current functionality (all the operations for the same Entity A and same attribute Attr1):

• a Context Provider registers in the Context Broker.
• another system or user makes an APPEND updateContext for the same entity and attribute.
• a queryContext or updateContext arrives: this operations are resolved locally, as it will be the case for any other operation -> the Context Provider registration has been rendered useless.

I think this cases are confusing for the user (at least they confused me during the IoT Agents tests :D ). If you register as the Context Provider of an attribute, you expect to get all the updates and queries on that attribute until your registration expires, and the current functionality inhibits this behavior. If the global idea is: 'APPEND only makes sense for locally resolved operations, UPDATE can be resolved remotely' then APPEND operation should raise an error when applied to attributes that are already managed by a Context Provider (and, conversely, a registration over an attribute that is already created locally should fail, as it will be useless, for all the operations will be resolved against the local entity).

[kzangeli]

We have 'only started' the implementation concerning context providers. More to come.

Personally I would like to see a URI parameter or something to inform the broker about entities/attributes that 'live elsewhere' - that are to be "treated as uncached".

[fgalan]

My only concern with this is if we have some case in which make sense to have the same context element at CB (locally) and CPr (remotelly), e.g. to use the CB one when the CPr is unreachable.

I haven't thought on this too much yet... but this issue is perfect to continue the conversation on this and, eventually, change CB functionality to behave that way.

[kzangeli]

I believe that there should be a way for a Context Provider to tell the Context Broker that an entity/attribute should be passive. This way, even if the entity/attribute is 'appended' to the broker, it would still be 'uncached'.

[fgalan]

I believe that there should be a way for a Context Provider to tell the Context Broker that an entity/attribute should be passive.

As far as I understand (please @dmoranj tell me if I'm wrong) that way already exists: every attribute registered at CB by IoTA (using NGSI9 regiterContext) is, by definition, a passive attribute.

[kzangeli]

It might be passive at creation time, but if anybody does an update/APPEND with that entity/attribute, then the broker will no longer treat it as a passive (uncached) attribute but as a local one (active).

The problem is that if this happens, the iot agent will still think it is passive (uncached) but this is no longer true.

If we could only tell the broker to treat the entity/attribute as uncached, even if it exists locally, this problem goes away.

[fgalan]

I have changed title to what I think is a more meaningful one. Some thoughts on this follow...

The overlap between local entities and registrations is not desirable, so it should be avoided. We can do this at two point:

1. At registration time
2. At update time

The problem is that we need both to fully solve this problem. If we only check at registration time (case 1) but an update creates a new attribute matching existing registration we are not solving the problem.

However, implement checking in case 2 could be problematic, as this is a very common operation and doing a query on registrations collection for to every regular update could involve a noticeable performance penalty.

So it seems we can only implement the check in case 1

As additional measure, we can also implement the checking at registrations browsing gime (GET /v2/registrations, etc.) and report overlapping entities in the response, eg:

"overlaps:" [
  {"id": "E1", "type": "T"},
  {"id": "E2", "type": "T"}
]

Ideally this field would be empty (and omitted in responses in that case).

This is not a perfect solution (perfect solution will be implement case 2 in addition to 1! :), but it can be useful to detect problematic cases.

[fgalan]

By the moment we have decided to leave this issue on hold. Registrations probably get deprecated soon, so it is not a good a idea to invest effort on registration-related features now.