Hello,
I’m currently struggling with a following problem. I’m currently working on a project porting a firmware to another chipset, and for testing purposes we’ve created jenkins pipeline that builds, and flashes the firmware and runs tests on it. However our test keep on failing intermittently due to otii.login errors , and I’ve been trying to sort this out. The error we reveive is usually the following:
An error occurred: {‘type’: ‘error’, ‘errorcode’: ‘Command timeout’, ‘cmd’: ‘otii_login’, ‘trans_id’: ‘382’, ‘data’: {}}
I’ve also tested the functionality by running the otii_server on our test machine from the command line, and running a simple python script that loops hundred times trough the script provided on your GitHub page under examples: user_management.py
Out of several runs, the failure rates range from 0 to 5 percent, and the failing ones receive always the same Exception as above. The version of out otii_server is 3.3.4, and we’re utilizing otii-tcp-client version 1.0.7.
Any input would be greatly appreciated.
Hi and welcome to the forum,
Our latest release 3.3.7 most probably have solved this issue, could you try this and get back to us if you still are having problems, please.
Best regards,
Björn
Thank you for the speedy response! The new version of otii seems to have solved our problems as you suspected, so I’m ever so grateful for the assist!
I was celebrating a bit too early, we’re still having problems. I’ll try to pinpoint the source of the error, which is a bit vague: timeout: timed out I’m also interested in the logs for otii_server, according to the release notes it should write logs to otii_server.logs, is there a default location for this file on Ubuntu?
The logs are located according to the following:
C:\Users<UserName>\AppData\Roaming\Otii 3\logs\ (Windows)
/home//.config/Otii 3/logs/ (Linux)
/Users//Logs/Otii 3/ (macOS)
Best regards,
Björn
Thank you, tomorrow I can start digging into the logs.
-Timo
So, I was trying to pinpoint the problem we’re having - haven’t had any luck yet. But was wondering if this is normal behavior for otii_server:
This particular moment of time is when during test setup, the Arc is shutdown trough set_main and started again, sleeping 5 seconds after each.
Looking through the logs I’ve gathered since I updated the otii to the version 3.3.7, after this particular section I’ve ran the pipelines twice and during those runs the only thing appearing in logs are those same two lines as above.
-Timo
Hi Timo,
This log is very interesting and to be able to dig deeper into this, may I ask you to create a case in our case system, please.
Best regards,
Björn
Ok, I did that. I also attached the otii_server.log to the case.
-Timo
To anyone interested, the real problem in our pipelines (timeout) was solved by the release candidate of the newest version of the otii software. Since then we haven’t had any problems with the timeouts. I must offer my deepest gratitude towards Quitech for speedy and efficient response!
