Fix calling stop monitored item callback. #132
Conversation
add verification code to template
|
@huebl , the PR is not ready to be merged. I'd like to write some unit tests before and discuss some questions. See my comments to the code. |
| @@ -582,8 +582,9 @@ namespace OpcUaStackServer | |||
| } | |||
|
|
|||
| // check monitored item list | |||
| monitoredItemIds_.erase(it1); | |||
| if (newMonitoredItemIds.size() > 0) { | |||
There was a problem hiding this comment.
I'm sure that this functional used to work correctly. But judging the history of file it could never work at all.
There was a problem hiding this comment.
I've understood. The problem is only for duplication monitored items inside of a single subscription. I tested my application with different clients.
|
The algorithm seems too complicated. Why we need to know IDs of monitored items to count them? We could just increment and decrement a monitored item counter. |
| @@ -582,8 +582,9 @@ namespace OpcUaStackServer | |||
| } | |||
|
|
|||
| // check monitored item list | |||
| monitoredItemIds_.erase(it1); | |||
There was a problem hiding this comment.
ok, The ID is not deleted if only one ID exists in the list.
There was a problem hiding this comment.
Yes, if there are other IDs, `newMonitoredItemIds' is not empty and I insert the rest IDs in L587.
| if (newMonitoredItemIds.size() > 0) { | ||
| monitoredItemIds_.insert(std::make_pair(baseNodeClass->nodeId().data(), monitoredItemIds)); | ||
| monitoredItemIds_.insert(std::make_pair(baseNodeClass->nodeId().data(), newMonitoredItemIds)); | ||
| return; |
There was a problem hiding this comment.
Oh , the same data will be inserted again.
There was a problem hiding this comment.
Not the same. newMonitoredItemIds has the rest of ID's and I re-insert them deleting old ID's before. See L585.
That is an error. The ID must always be removed from the list. If you take it exactly, the bookkeeping of Start and Stop would have to be independent of the callbacks. The following combinations are possible.
We should open a bug for this bug. |
The IDs are needed for the unique identification of parameter sets (sampling interval, queue size, ... ). Several Monitored Items for the same Node ID can have different parameter sets. The parameter sets are transferred to the application with the ID (Not yet in the current implementation). In the Monitored Stop, the ID is used to identify the Monitored Item inside the application. |
|
I accidentally executed the pull. Sorry. |
atimin
changed the title
If several monitored items are created for a node in the same subscription, a user application becomes no callbacks when all of them will be deleted.