Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove guard for initial notifications #2044

Open
fgalan opened this issue May 21, 2021 · 3 comments
Open

Remove guard for initial notifications #2044

fgalan opened this issue May 21, 2021 · 3 comments

Comments

@fgalan
Copy link
Member

fgalan commented May 21, 2021

Initial notifications are going to be deprecated in Orion Context Broker. They are being deprecated in Orion 3.1.0 and the removal is expected for 3.2.0.

When that moment comes, the Cygnus guard code to "protect" against initial notification will no be longer needed.

This PR can be an useful reference: #2043

@fgalan
Copy link
Member Author

fgalan commented May 21, 2021

Similar to issue telefonicaid/perseo-fe#526

@jaimeventura
Copy link

Hey @fgalan,
I found this issue after hitting a problem with a initial notification with around 100k entities (i would love to talk to you about this number, but thats another subject.)

Anyway, I came across the issue on orion, about Initial notifications being deprecated, and since its mentioned here that "if you need to know the status of your system at subscription time, then use GET /v2/entities with proper pagination." i have a doubt.

I understand the reasons for deprecating this feature.
But, for instance, when using cygnus with the Postgresql sink, how one can load every entities prior to the subscription?
And, say 'all' entities are previously loaded to that database, how may one guarantee that there where no changes between the end of the loading process and the time the subscription was issued?

(Or maybe im misunderstanding the use of cygnus?)

@fgalan
Copy link
Member Author

fgalan commented Jun 16, 2021

I found this issue after hitting a problem with a initial notification with around 100k entities (i would love to talk to you about this number, but thats another subject.)

I understand that 100k refers to the payload size of the entities, no the number of the entities. Initial notification always included as much as 20 entities (see telefonicaid/fiware-orion#591).

However, initial notification feature has been already removed in master (so in next version, Orion 3.2.0 will not be) so talking about this is probably not needed :)

Anyway, I came across the issue on orion, about Initial notifications being deprecated, and since its mentioned here that "if you need to know the status of your system at subscription time, then use GET /v2/entities with proper pagination." i have a doubt.

I understand the reasons for deprecating this feature.
But, for instance, when using cygnus with the Postgresql sink, how one can load every entities prior to the subscription?
And, say 'all' entities are previously loaded to that database, how may one guarantee that there where no changes between the end of the loading process and the time the subscription was issued?

(Or maybe im misunderstanding the use of cygnus?)

The usual usage case in Cygnus is to persist history, i.e. changes in the entities. The initial status of the system is not considered history, from the point of view of Cygnus, only the changes since the feeding subscription is created. In fact, current Cygnus implementation discard the initial notification and pay attention only to regular (non-initial) notifications.

However, if you need to set an "initial change" in your storing system (Postgresql in your case) for every entity in your system, you have two alternatives:

  1. Pre-create that entry in the storing system, using some out-of-band mechanism. For instance, a script that reads entities for CB and insert in Postgresql Cygnus tables accordingly
  2. Trigger a notification with the initial value. You don't need to change the entities, you can use the ?options=forcedUpdate (described here) with the current value of some triggering attribute in the subscription.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants