Attention is currently required from: laforge, pespin.
1 comment:
Patchset:
I see this was resolved but there was no fedbac? I also couldn't see ant changes in the code?
you are missing the use of array indexes in this API verifying rate counters via the ctrl interface.
In addition to handling single objects, we also support handling N object instances at once in the counter validation API.
For example, for MSC tests, we always have msc.0, msc.1, msc.2 in sequence.
The API is such that you fetch all the (interesting) counters for all three instances at once. You get back an array of counter sets, the first array entry is for msc.0, the second for msc.1, etc.
This array is then a cache; the test increments the expected values in the array, and then verifies it again with results fetched later.
Crucially, the array index so far serves as the ID used on the CTRL interface.
This was the result of first using the counter API in tests, and being annoyed by the repetetive bloat needed for multiple objects.
Our ttcn test that I am trying to fix here already follows this logic of asking for hnb.0, and looking at the first entry of the returned array. -- turns out hnb.0 doesn't work reliably, and we need to use the name instead.
We could keep the indexed-array stuff for index-able objects only, and force single-object access for by-name access, but that would probably introduce code duplication of the CTRL functions for counters. Callers then also need code dup for fetching N objects at once.
Hence, the mapping from index to name: it allows using the same logic, the same API and the same CTRL code, just for names instead of indexes.
Define a list of names once, then continue using array indexes.
This also reduces repetition of name strings in ttcn code, cleaner.
It also allows iterating the counters of instances.
I do not want to remove this layer of abstraction for by-name counters, because it is powerful.
To view, visit change 37882. To unsubscribe, or for help writing mail filters, visit settings.