I am encountering an issue with a protocol I have written which is failing to update the parameter table display in a specific element.
Within the protocol I use a QAction to populate additional columns within a table based on some other values in the table which are fetched via SNMP.
The QAction is triggered on a change to the overall table and uses the Notify Type 220 (NT_FILL_ARRAY_WITH_COLUMN) to update two columns within the table which are calculated from the values fetched via SNMP. These columns are defined as type=”retrieved”.
This protocol/QAction is working correctly for a number of other elements, but for this one specific element, the retrieved columns (Output Power and Reflected Power) are not being updated in the displayed table as shown below:
However if I make a duplicate copy of the element on the same DMA, then the columns are updated and displayed correctly in the duplicate element as shown below:
This would indicate that is is nothing to do with the device itself but something specific to this one element instance.
Looking at the system log for the affected element, it has the following lines logged, which do not appear in any other elements including the duplicated element running the same protocol.
2023/09/26 10:40:58.577|SLElement.exe|5360|CElement::Subscribe|INF|-1|subscribe (31144/19959): 31144/19959 VT_ARRAY|VT_VARIANT (7) ~ 0 VT_I4 : 5 ~ 1 VT_I4 : 4100 ~ 2 VT_ARRAY|VT_BSTR (1) : VALUE=4101 == 6 ~ 3 VT_I4 : 1 ~ 4 VT_I4 : 1… Cookie 162286
2023/09/26 10:40:58.583|SLProtocol – 16932 – Element Name|5328|CProtocol::HandleAnotherTelnetClient|DBG|0|Telnet clients connected Primary = 1, Derived = 0
2023/09/26 10:40:58.680|SLElement.exe|14968|CElement::Subscribe|INF|-1|subscribe (31144/19959): 31144/19959 VT_ARRAY|VT_VARIANT (7) ~ 0 VT_I4 : 5 ~ 1 VT_I4 : 4100 ~ 2 VT_ARRAY|VT_BSTR (1) : VALUE=4101 == 6 ~ 3 VT_I4 : 1 ~ 4 VT_I4 : 1… Cookie 162286
2023/09/26 10:40:58.685|SLProtocol – 16932 – Element Name|5328|CProtocol::HandleAnotherTelnetClient|DBG|0|Telnet clients connected Primary = 1, Derived = 0
2023/09/26 10:40:58.791|SLElement.exe|14968|CElement::Subscribe|INF|-1|subscribe (31144/19959): 31144/19959 VT_ARRAY|VT_VARIANT (7) ~ 0 VT_I4 : 5 ~ 1 VT_I4 : 4100 ~ 2 VT_ARRAY|VT_BSTR (1) : VALUE=4101 == 6 ~ 3 VT_I4 : 1 ~ 4 VT_I4 : 1… Cookie 162286
The parameter id of the table with the issue is 4100 which corresponds to the details logged.The DataMiner version this is occurring on is 10.3.0.0-13088-CU4.
While I can get around this issue by effectively replacing the element with a duplicate copy, I would like to know what is causing the issue.
Hi,
-I’m wondering where the retrieved columns are present: between the snmp type columns or after the snmp type columns? There were known issues when retrieved columns were present between snmp type columns which has been fixed since 10.3 CU5. The version 10.3 CU4 that is being used here does not contain that fix yet. See release notes here
-Other things that could be done to find the root cause is to add temporary logging in the QAction (e.g. create a temporary version that only this element is using): add logging when the QAction gets started, log out the values that are passed to the NotifyProtocol 220 so you know that the notify call actually does get executed and with what values. This logging could then be compared with an other element that is able to have the values displayed. Another possibility could be to debug with a DIS inject so breakpoints can be set and code can be investigated, but that is not really advised on a production setup, and adding a simple log line instead is more easy.
Regards,
That seems to be something that would have to be investigate more in depth to know why the inputParameters object contains empty index values.
I’m wondering when using NT_GET_TABLE_COLUMNS notify what the result then would be? (see: https://docs.dataminer.services/develop/api/NotifyTypes/NT_GET_TABLE_COLUMNS.html ). If that works then it can be used as an alternative instead of the inputParameters, and is actually something that we’re mostly using instead of the inputParameters.
What could help to investigate the root cause of the inputParameters that has empty keys, is to add a Thread.Sleep of a couple of minutes just before executing the notify 220. While the QAction is sleeping (being blocked), take high memory dumps of SLProtocol and SLScripting processes with the Log Collector. And also a DELT package export of the element. Preferably also have the QAction sleeping at the same time of the element that is working correct. This way we can have a better view of all the arguments in memory and compare it between the working and non working element. Best to contact our Techsupport so they can guide you through the necessary steps and they can indicate where to upload the memory dumps.
I have tried using both NT_GET_TABLE_COLUMNS and NT_GET_KEYS_SLPROTOCOL within the same QAction and the index/primary key column values are being returned as empty in both cases.
As you say, looks like more investigation required to get to the root cause.
Indeed, if NT_GET_TABLE_COLUMNS is also returning empty keys while there are values present, then it’s best to contact Techsupport. Memory dumps and DELT export of the elements should give a better idea of what is going wrong.
Regards,
Thanks Laurens,
No the retrieved columns are the last columns in the table, the SNMP columns are the first ones in the table.
I took your advice and added some logging in the QAction and the problem is that the index column values are all empty.
I am passing the table in as an inputParameter to the QAction and using protocol.GetInputParameter(0) to extract the columns.
So the NotifyProtocol is obviously failing as primary keys are all empty strings.
In the working duplicate element, the entries are the expected index values.
What is really weird is that the index column values are shown in the displayed table but not being passed in via the input parameter.