Wrong order of BIRTH/APPLICATION certificates for custom APP IDs registration about kura HOT 16 CLOSED

Hello,
do you have some logs to share that show the issue?

from kura.

Hi @MMaiero,
here are the relevant device events: container_device_events.csv
As you can see, if you order them by the Created On field, the last event is missing the USER-INTERFACE-V1 custom APP ID.

I confirm that by creating an APP ID caching mechanism in one of our custom components and publishing the certificate after 5 seconds the problem no longer occurs.

from kura.

Are you seeingg this issue with only your custom component (USER-INTERFACE-V1) or also with other "native" Kura components?

from kura.

This problem apparently occurs only with "non-native" APP IDs. I imagine that the native components are loaded before the connection is established due to dependencies and therefore the problem does not manifest because the APP IDs have already been collected.

from kura.

The code that manages that publishing is this one:

From that point on the app should be recorded in a map. The only point where I see a removal from that map is this one:

from kura.

That's right, just to solve the problem of multiple sequential sending of multiple "non-native" APP IDs, I had to create three new methods, to avoid immediate sending of the certificate for each APP ID, which can cause server-side processing in the wrong order.

These are the methods in kura/org.eclipse.kura.api/src/main/java/org/eclipse/kura/cloudconnection/request/RequestHandlerRegistry.java interface:

    public void registerRequestHandlerNotPublish(String appId, RequestHandler requestHandler) throws KuraException;
    public void publishRegisteredRequestHandlers() throws KuraException;
    public void unregisterNotPublish(String appId) throws KuraException;

As can be guessed, the *NotPublish methods simply add or remove the APP ID in/from the map and the publishRegisteredRequestHandlers method is called after a certain period of time and only deals with sending the certificate.

The call to these new methods, however, is currently done by us externally by one of our dedicated components and in my opinion should be included "natively" in kura.

from kura.

Wouldn't be better to add a (maybe configurable) delay in the app processing? So the API stays the same and the code changes to accomodate this need?

from kura.

We have multiple OSGi bundles that can load dynamically in rapid succession, and we have no control over the loading sequence and timing.

from kura.

that's why I was suggesting a configurable delay to be specified in the Request Handler preferences so that the registering operation can stay the same. A separate thread can proceed on the APP/BIRTH publishing after x seconds or x seconds after the last registration events so that you can send only one message to the cloud with all your apps in it

from kura.

It is not acceptable for us to delay loading our bundles, which may number in the dozens and interface directly with hardware components that need to be available to other bundles as soon as possible.

from kura.

No, maybe I was not clear on my proposal: my idea would be to add a thread in CloudServiceImpl that processes the registrations in

from kura.

Sorry, I didn't understand correctly.
Yes, that is exactly what would be needed.
I also don't understand why the APPLICATION certificate is not sent the same way in CloudConnectionManagerImpl and so that class should be corrected as well.

from kura.

Sorry, I didn't understand correctly.
Yes, that is exactly what would be needed.

That would be a great contribution for the project if you are willing to partecipate to it. We would be happy to have new contributors to Eclipse Kura!

I also don't understand why the APPLICATION certificate is not sent the same way in CloudConnectionManagerImpl and so that class should be corrected as well.

Not sure there too, it may be because of the different contract.

from kura.

Thank you very much for your reply.
As soon as I have some time I will create a PR.

from kura.

This issue is stale because it has been open for 60 days with no activity.

from kura.

This issue was closed because it has been inactive for 14 days since being marked as stale.

from kura.