-
Notifications
You must be signed in to change notification settings - Fork 42
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
Notification problems after a while #1390
Comments
ok, that's not good ! I'd like you to test something, let me explain ... I've been working quite a while on getting rid of the old deprecated mongo driver. Anyway, this work reimplements the entire database layer and with that quite a lot of the logic. I'd say about 33% of the broker has been rewritten. I'd like you to test the new implementation, as, fixing bugs in the old deprecated code is not something I really have time for. So, please start the broker with the option Might be your problem is fixed in "experimental mode". Please test this and let me know.` |
Hi @kzangeli, I switched to experimental. I'll let you know if the problem still exists tomorrow!
|
Sorry, not a clue. [ Surprised to see "POST /context-broker/ngsi-ld/v1/entities/?" ... Question mark without url params??? ] |
Yeah that's just my component that generates Kong calls, if there are no parameters it still inserts the '?'. I can change that but it worked until now :p Sorry, seems that I missed the orion trace indeed, this is the full (relevant) trace:
My component (C) and context broker (B) interact like this: Could it be that the experimental version of the context broker cannot handle an incoming request while a notification request is still being processed? The log shows that the Kong module fails before the orion-ld notification fails, and only after that, the POST request comes through. However, the POST request should be executed before the notification fails, as it was sent before the notification status code was sent. You can also see this in the logs of the custom module: The new request is the notification, the status code is only returned at the end of the log.
|
See this in the traces?
Seems like the receiver of the notification responds with a 500. Let's go one step more then. [ The entire subscription/notification algorithm has been reimplemented from scratch ] |
Yeah, that's my custom component. It just returns 500 if it fails to process the request fully. The traces at the bottom of my previous reply are the traces of the component that receives the notification. In this case, the custom component receives a request with a specific subscription id, in this case it's transport6. Locally, the custom component has a set of rules it has to follow for each incoming request. In this case, it needs to create new entities when a transport6 notification comes in, based on the information inside the notification body. It tries to create the new entity, but fails as it receives a timeout from te context broker. Up until this point, the notification request is still not closed by this component, no status code has been sent. If the entity was created, or the entity already existed, it would've responded with a 200 OK. Because I didn't know at the time what could go wrong, I just chose to respond with a status code 500 in the case that something else failed. In this case, the custom component got a failed request from Kong, which got a timeout from orion, thus the custom component returns status code 500. (or is it better to just always return 200 when the notification was received?) What I find weird in the logs, is that orion shows the failed notification first, and then it handles the POST. But the POST was requested (by the custom component) bfore it ever returned a notification status code. I could be wrong, maybe I'm looking over something, but I never had this problem with the non-experimental version |
Only thing I saw in the brokers traces was a timeout in the response of the notification. We'll need more info to understand the problem here. And, to answer a question you made earlier: Need more traces from the broker. |
@kzangeli
|
ORION_TRACE ... that's not the right env var - wrong prefix (for Orion, not Orion-LD)
|
Yeah I changed that, I deleted the reply because I noticed the error :) |
Yeah, I noticed. Seems like you get no notification due to an entity type mismatch. |
@kzangeli |
So, after the timed out notification we see this:
So, that creation seems to have worked. I'll have a look at the timeout for notifications (I might have hardcoded that to 5 secs or something). Also, as you might have seen, the entity id/type are not present in the traces (Request Payload Body). |
The entity type was Cargo, the id was urn:ngsi-ld:Cargo:001. A link header was provided with a link to the context file. I can edit my custom component to show more detailed logs and paste them here if you want, with all the detailed request info. |
Hi @kzangeli, I initially forgot to reply with my full custom component log, sorry! NOTE: I can create Cargo entities just fine if I directly do the call via postman/console application. The problem only seems to occur when a notification is being processed, such as the situation described in the logs.
|
Hi @kzangeli Is there any progress on this issue, or is it totally unknown as to what the cause of the problem might be? (both the subscriptions not working after a while in non-experimental mode and the issue with experimental mode). No hurry though, I'm just curious :) |
Yeah, very sorry, haven't had time for this yet. |
Hi @kzangeli, any updates on this? Just in case I missed something :) |
Sorry, just back from vacation and no progress on this issue. |
For my use-case I use a lot of subscriptions, but they seem to have some problems. In my case, there is a custom external component that, on startup, dynamically creates subscriptions within the context broker if they do not exist yet.
However, I noticed that the subscriptions will not fire notifications after a while of being created. As an example, I started my prototype application today and the subscriptions that were created yesterday did not fire. I'm not sure how this happens or what the specific conditions are, but the
/ngsi-ld/v1/subscriptions/
endpoint showed the subscriptions without thetimesSent
,lastNotification
,lastFailure
,... metadata, indicating that they never sent any notifications. My solution in this situation is to delete all subscriptions, restart that custom component, it recreates all subscriptions in exactly the same way, and then it works again.Almost all of my subscriptions have the same properties, so maybe it has something to do with certain features? Below is an example of such a subscription:
Any idea as to why this might happen?
The text was updated successfully, but these errors were encountered: