I am trying to repeatedly update some values in C++ based on telemetry coming from a lightstreamer server. This telemetry is real-time data from the International Space Station (ISSLive), that I will be using to articulate a VR simulation model of the same. I have the VR simulation side of this covered; I just need help with the data stream. Here's a public gist of the code: https://gist.github.com/connorjak/9f853bb83559976e12c9e38811c3c0af
Working Starting Point
The starting point of this project is the ISS-Mimic project. Here is their (working) architecture:
(Running on Raspberry Pi)
- Python
database_initialize.py
removes then reinitializes a SQLite3 database in/dev/shm/iss_telemetry.db
- Python
GUI.py
establishes a SQLite3 connection to the same directory, appliesisolation_level = None
to the connection object - At some point in
GUI.py
, a Python subprocess is opened forISS_Telemetry.js
- NodeJS
ISS_Telemetry.js
establishes a SQLite3 connection to the same directory, with this line:var db = new sqlite3.Database("/dev/shm/iss_telemetry.db", sqlite3.OPEN_CREATE | sqlite3.OPEN_READWRITE);
ISS_Telemetry.js
establishes a LightstreamerClient connection to the lightstreamer server, withsetSlowingEnabled(false)
ISS_Telemetry.js
listens on the Lightstreamer connection and updates the SQLite database with new data.GUI.py
goes on to repeatedly execute select queries and fetchall() to get the entirety of the telemetry every tick.
Non-Working Current Architecture
Now, here is my architecture, with key differences in bold.
(Running on Windows 10 1903, WSL with Ubuntu 18.04 LTS)
- C++
ISSLIVE.cpp
callssystem(...)
to start and wait for Pythondatabase_initialize.py
- Python
database_initialize.py
removes then reinitializes a SQLite3 database in/dev/shm/iss_telemetry.db
- C++
ISSLIVE.cpp
establishes a SQLite3 connection to the same directory, does not applyisolation_level = None
to the connection object (can't find equivalent functionality in C API) ISSLIVE.cpp
callssystem(...&)
to start and not wait for NodeJSISS_Telemetry.js
- NodeJS
ISS_Telemetry.js
establishes a SQLite3 connection to the same directory, with this line:var db = new sqlite3.Database("/dev/shm/iss_telemetry.db", sqlite3.OPEN_CREATE | sqlite3.OPEN_READWRITE);
ISS_Telemetry.js
establishes a LightstreamerClient connection to the lightstreamer server, withsetSlowingEnabled(false)
ISS_Telemetry.js
listens on the Lightstreamer connection and updates the SQLite database with new data.ISSLIVE.cpp
goes on to repeatedly execute select queries (sqlite3_exec(...)
) to get the entirety of the telemetry every tick. The queries are passed with a callback to print all received table data to cout.
The Problem
Instead of going to the callback function and printing any data at all, sqlite3_exec(...)
returns error code 15: PROTOCOL (Locking Protocol error). This happens after exactly ten seconds.
The Question
What should I do to debug this? I tried valgrind callgrind to pick out computation offenders, but it appears that whatever is happening is not compute-heavy (very low compute time spent in this code).
I could also try to replace this architecture with another. Should I? What would I use? I can't change the source server of this data. I had a false-start earlier with cpp-lsclient, a C++ implementation of Lightstreamer. That repo appears to only have a partial implementation of lightstreamer.
More Info
- isolation_level = None should relate to the
autocommit
mode in SQLite.autocommit
mode is on currently in the C++ code; I checked. database_initialize.py
finishes (and closes its connection) before anything else pertaining to the database runsISS_Telemetry.js
closes when the C++ application closesISS_Telemetry.js
appears to be working correctly; data is flowing in properly. It's possible there's still an issue in this code.- Python 3.6.8
- NodeJS v12.13.1
- npm 6.12.1
- Javascript node-sqlite3 4.1.1 (actual sqlite library version ~3.30)
- C++ sqlite3 3.22.0
- lightstreamer-client 7.3.1
- C++14 std
- C++ code operating inside a pthread as a dynamically linked library, alongside a highly-multithreaded simulation platform