-
Notifications
You must be signed in to change notification settings - Fork 266
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
from=, corr=, srv= and subsrv= are not correctly propagated in transactions corresponding to notifications triggered by updates in log traces #3073
Comments
Useful scripts to debug this:
|
Fixed by PR #3414. Let's compare the one in this issue with the problem (top):
with the one in the PR's branch:
All using the same corr/srv/subsrv/from, two transactions (0001 for the update, 0002 for the notification sent). Check with all notification modes (permanent, transient an threadpool) in both cache and no-cache modes (i.e. the six possible combinations) and works fine. |
[srv=pending | subsrv=/BBB] Don't you know the srv at this point? there is any difference with subsrv? |
Yes, the first two ones are weird with regards srv= and subsrv=
I think it's easy to improve. I'll do: |
PR modified and now it looks like:
|
Let's consider the following situation: 1 entity with 1 subscription associated, in a given service and subservice (e.g. "foo" and "/far). Orion is running with log level INFO. An update on the entity is done, generating a notification. This involves the following log traces:
trasn= ended in 6 corresponds to the update and transaction 7 to the notification. Note that in that one corr= is N/A and the others (srv=, subsrv= and from=) are "pending" instead of having the same values than transaction 6 used.
Some additional findings:
-notificatonMode
. At least it occurs in the transient and threadpool cases.Also related wit this (but minor) are the two messages at the bottom, using N/A for the four fields. Actually they are related with the notification transaction, but probably are using N/A as they are functions in the cache management logic. Have a look to this also, in the case it has an easy fix.
The text was updated successfully, but these errors were encountered: