-
Notifications
You must be signed in to change notification settings - Fork 43
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
Orion container crashes when user tries to add data to an entity that doesnt exist. #1714
Comments
That sounds like an old issue Infixed some time ago. What is the tag of the broker? (not clear ...) |
No, just think of the example I gave you on the subscriptions issue, where you skip the entity creation and subscription requests and just do the add data when the entity and subscriptions dont exist yet. In the app I am developing I have made a frontend form for users to create orion entities for iot devices dynamically and I discovered that issue in the process of developing the app. I don't think that it was intended for the container to crash if somehow, because of a bug in code a wrong post request was made. |
Ok. Try PATCH /entities/[entityId]. |
Ok I will try to add data using PATCH then. In regards to the application/ld+json, I tried doing something like
the link has content like:
but the entities dont get saved correctly in mongo. They look like:
when they should be like:
which is done with the initial way I create entities that I showed in the example above. |
ok, that's funny ... The long name But, only if you use the attribute name Show me the exact URL, payload body, and headers you used when creating this entity. |
This is the exact post request I make to create an entity using the method you suggested:
the only real difference is the server IP which is something like 11.100.0.35 the link with the context I mentioned in my previous response
has real data, the only difference is I have even more context attributes on my real link but thats it. |
And, in that context (https://mysite.com/api/ngsi-ld-attributes), "temperature" is present, with the long name that is already mentioned. |
Ah, that last piece of information was interesting.
|
Still face the same problem:
with post request the same as before it saves the entity like:
|
That's not possible! :) The "link" between "temperature" and "attributes" of the core context is still there, and it should not be. |
ok fixed it. It turns out when using link it downloaded the context and saved it in mongo db. I had to manually delete it. One question, if I add more attributes to the context after I have used it to create an entity will it redownload it and save it to mongo? Also is this normal:
I mean the way it saved the url cause with the old method it saved it like:
|
Yes, that's what I was referring to when saying it was using the old context. |
The whole idea behind the context cache is to avoid to re-download what I already have. That's an extremely slow operation. Look into the API endpoints fro |
I looked up the service routine (endpoint) for you (much easier for me). Try this:
That operation is supposed to reload your context and persist the new content under the same context. |
Thanks for the info and the time. |
Very happy to help :) |
I tried: where this fdabaae4-b098-11ef-b78e-0242ac120106 is the _id of the mongo entity that has the downloaded context but it wasnt deleted |
The Entity itself will not be deleted. No entity will be touched |
There is another bug I found regarding the method of creating entities with link. Here are my requests: Create entity:
Create subscription:
the entity in mongo is saved like:
The problems start after I try to patch:
the mongo entity changes to:
notice how the attr names became 2:
Also if I patch again they will become 3 attr names instead of remaining one unique for each attribute like it happened with the old method of creating entities. I just wanted to replace with the latest value. |
Wow, weird things are happening to you!!! :)) |
It's not about the mechanism of giving the context. |
The context is like this:
Also regarding the patch request I mentioned. Is creating duplicate entries in "attrNames": [ an intented functionality every time a patch request is made?
I noticed and you mentioned it as well that the mongo entity of context doesnt change from the original one after running the delete request. The attributes that were added to the context after the initial load are expanded correctly after I update the context in the site page and run the delete request. The problem I have is since the mongo db entity for context doesnt change that means if orion container stops or is deleted the attributes that were added to the context after the initial download wont be included in the context anymore and if I try to create a new entity with those attributes without reloading the context again they wont have the correct url. Is there a way to force orion to recreate the context entity in mongo as well as refreshing its context cache? If there isn't I guess I have to go back to the previous way of creating entities without link because my context is dynamic since users in my app can add attributes to the context when they create a new entity that has an attribute that doesnt exist in the context. The old method didn't have any of these problems like the backslashes in link, the duplicate entries in attrNames array that get added every time on patch and also the problem with the context that there isn't a way to recreate the mongo entity after initial download and that means that if orion container stops then the additional context is lost and needs to be reloaded manually, |
Also for the variables in docker compose:
ORION_LD_PORT=1026
ORION_LD_VERSION=1.7.0
QUANTUMLEAP_VERSION=1.0.0
QUANTUMLEAP_PORT=8668
CRATE_VERSION=latest
MONGO_DB_PORT=27017
MONGO_DB_VERSION=latest
REDIS_PORT=6380
REDIS_VERSION=6
for REDIS_USERNAME and REDIS_PASSWORD put whatever
If you just start all the containers and then try to add data to an entity that doesnt exist the orion container crashes. You could say I could run a cron job to check if the orion container stopped working for some reason and work around this issue but I dont think the intended functionality is for the container to crash every time someone does a wrong request. This was how I discovered the other issue with subscriptions I posted last week.
The text was updated successfully, but these errors were encountered: