Hdb++ - Event Subscriber not start archiving at startup

# 6 years ago
KKedron	Dear all, I write to ask your help on one issue connected with properties of EventSubscriber. My problem is with properties StartArchivingAtStartup, because I want start archiving the attribute after the start/restart of Device Server. I setup the Class Properties on the true (like screenshot) and this dosen't work. Device's turns on normally but don't start archive the attributes, I must run start command manualy. I checked the code of Device Class but I have found't the line resposible for running the archving the all attribute's automatic after starting the device's, so I can't debug this problem. Some ideas? Thank's for advice. Edited 6 years ago Attachments: 21Kb

# 6 years ago

Dear all,

I write to ask your help on one issue connected with properties of EventSubscriber. My problem is with properties StartArchivingAtStartup, because I want start archiving the attribute after the start/restart of Device Server. I setup the Class Properties on the true (like screenshot) and this dosen't work. Device's turns on normally but don't start archive the attributes, I must run start command manualy.

I checked the code of Device Class but I have found't the line resposible for running the archving the all attribute's automatic after starting the device's, so I can't debug this problem.

Some ideas?

Thank's for advice.

Edited 6 years ago

# 6 years ago
Reynald	Hi, If I remember correctly, StartArchivingAtStartup property is obsolete since the Archiving contexts/strategies feature have been implemented. You should configure your attributes archiving strategy, which will list the different archiving contexts when your attribute must be archived. For instance, in our case, we have defined the following contexts: Run. Restart, Shutdown and we have as well ALWAYS and Never contexts. There is a memorized attribute named "context" in the HdbEventSubscriber class. Each event subscriber will automatically start archiving the attributes which have to be stored in the current context. So, in your case, you should check your archiving strategies for your attributes and ensure the context of the HDB++ Event Subscribers taking care of these attributes are currently with a Context attribute correctly set and you should ensure your attributes archiving strategies are correctly configured. I hope this is clear and helps a bit. Kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 6 years ago

Reynald

Hi,

If I remember correctly, StartArchivingAtStartup property is obsolete since the Archiving contexts/strategies feature have been implemented.
You should configure your attributes archiving strategy, which will list the different archiving contexts when your attribute must be archived.
For instance, in our case, we have defined the following contexts: Run. Restart, Shutdown and we have as well ALWAYS and Never contexts.

There is a memorized attribute named "context" in the HdbEventSubscriber class.
Each event subscriber will automatically start archiving the attributes which have to be stored in the current context.
So, in your case, you should check your archiving strategies for your attributes and ensure the context of the HDB++ Event Subscribers taking care of these attributes are currently with a Context attribute correctly set and you should ensure your attributes archiving strategies are correctly configured.

I hope this is clear and helps a bit.

Kind regards,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 6 years ago
KKedron	Hi Reynald, Now I understand. Thanks a lot for advice. But I saw some not intuitive behavior. Like you know by default all attributes in AttribueList property have strategy setup on ALWAYS. Default ContextList attribute is setup on: ALWAYS:always stored RUN:stored during run SHUTDOWN:stored during shutdown SERVICE:stored during maintenance activities After init new device, Context attribute have 'ALWAYS' read value and None in set value. But this don't start all attributes (with ALWAYS strategy setup in properties). I have to manually write 'ALWAYS' value to Context attribute to start archiving attributes in ALWAYS group. Thanks to this operation, attributes are archived automatically after restarting DS Kind regards, Krystian

# 6 years ago

KKedron

Hi Reynald,

Now I understand. Thanks a lot for advice.

But I saw some not intuitive behavior. Like you know by default all attributes in AttribueList property have strategy setup on ALWAYS. Default ContextList attribute is setup on:
ALWAYS:always stored
RUN:stored during run
SHUTDOWN:stored during shutdown
SERVICE:stored during maintenance activities

After init new device, Context attribute have 'ALWAYS' read value and None in set value. But this don't start all attributes (with ALWAYS strategy setup in properties). I have to manually write 'ALWAYS' value to Context attribute to start archiving attributes in ALWAYS group.

Thanks to this operation, attributes are archived automatically after restarting DS smile

Kind regards,
Krystian

# 6 years ago
Reynald	Hi Krystian, I agree with you. The behaviour you are observing is counter-intuitive. If an attribute is configured to be always stored, it should always be stored… This looks like a bug. Cheers, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 6 years ago
lorenzo	Yes, that is because Context is a memorized Attribute, and you need to write it at least once… Lorenzo

# 6 years ago
Reynald	lorenzo Yes, that is because Context is a memorized Attribute, and you need to write it at least once… Lorenzo Sure. But ALWAYS context is already a special context and I think we could/it would be nice to do something to ensure the attributes which are configured to be always stored are always stored, even before the first "context" attribute write. Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 6 years ago

Reynald

lorenzo
Yes, that is because Context is a memorized Attribute, and you need to write it at least once…
Lorenzo

Sure.
But ALWAYS context is already a special context and I think we could/it would be nice to do something to ensure the attributes which are configured to be always stored are always stored, even before the first "context" attribute write.

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 6 years ago
Reynald	On the other hand, there is another special context named "Never" which can be set by the user. If we set The HDB++ Event Subscriber Context to "Never", the event subscriber will not store any attribute. It looks like the EventSubscriber is behaving as if the context was set to Never when Context has not been initialized yet. This is the choice which has been made. Why not? If we keep it like that, it would be nice to document this behaviour (if not already done) so people don't get confused. Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 6 years ago

Reynald

On the other hand, there is another special context named "Never" which can be set by the user.
If we set The HDB++ Event Subscriber Context to "Never", the event subscriber will not store any attribute.
It looks like the EventSubscriber is behaving as if the context was set to Never when Context has not been initialized yet.
This is the choice which has been made. Why not?
If we keep it like that, it would be nice to document this behaviour (if not already done) so people don't get confused.

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 6 years ago
lorenzo	I think the original reasoning was to keep separate the configuration phase and the actual start of archiving. I'd still prefer to keep it as it is, but I agree that this needs to be documented.