Hello All,
I have this message in one of our element logs and am trying to make sense of it:
2023/06/15 14:31:00.340|SLProtocol - 2880 - |6896|ARRAY::SetAt|ERR|-1|[Cell update] Table [JobPlanningFileStatusTable [11500]] [Column: JobPlanningFileStatusTableStatus [11506]] Set on row 1984 [only 1984 row(s) available]
and we also have this message too:
2023/06/15 14:31:00.256|SLProtocol - 2880 - |6896|ARRAY::SetAt|ERR|-1|[Cell update] Table [JobPlanningFileStatusTable [11500]] [Column: JobPlanningFileStatusTableLastUpdate [11505]] Set on row 2003 [only 1984 row(s) available]
As you can see sometimes the number of rows is different to what is available and sometimes it is the same.
I believe it is stopping rows being set on the table 11500 correctly. Could someone shed some light on to this issue?
Thanks,
Ryan
Hi David,
It could definitely be the cause of the problem.
Although DataMiner does support a certain level of multithreading and asynchronous programming it is not immune to the inherent challenges that come from it.
If you have 2 places in your code that are trying to modify data at the same time, you could end up with data inconsistency if you do not use some safety checks like a locking mechanism.
My advice here would be to either not use the asynchronous calls or to ensure you implement a lock mechanism around your sets and deletes that ensures data integrity prior to sending the commands to confirm the errors you see in the logging go away.
Hi Ryan,
It is tricky to give you a complete answer without knowing the full context but some pieces of information I can give you is that the row "number" is 0-based, so when DataMiner says it only has 1984 rows it means it will accept sets for rows 0 to 1983.
And when you see that it fails for 1984 it is trying "one too many" and when you see 2003 it is trying to set on 20 rows past what it has available.
Also, the error originates from a method doing cell sets but without knowing how the connector works I cannot be sure what is happening or what is the source of the data/sets.
Would you be able to shed some light on how the connector works?
Hi João,
Thank you for your answer, please refer to my colleagues comment posted above for some more context.
I am not familiar with the term connector, what exactly is that.
Thanks,
Ryan
‘Connector’ is a term that we use interchangeably with the term ‘driver’. The XML file that defines how DataMiner can interact with a third party product.
Hi Ryan,
My apologies for the confusion with the terms used, but indeed as Ben mentioned ‘Connector’ is the term we use to refer to ‘drivers’ or ‘protocols’.
And regarding the original question, with your colleague’s extra info, I believe the issue could be indeed due to the asynchronous nature of the code you have.
DataMiner when it receives commands tries its best to validate the data that comes in to ensure data integrity but when it is not possible it returns errors such as the ones you saw to warn users of something that went wrong.
We would be interested to know whether this code is thread safe.
This occurrence of SetRow is happening in an asynchronous call.
There is potential for another action to concurrently delete rows from this table using the protocol.Delete() API call.
Would this be likely to cause the behaviour seen here?