We are having some issues in our code when streaming data to a file.
Details: Our setup uses the Workspace client feature to load Matlab and Python client bridges. Our Python client bridge code uses the IPCClientConduit to register a callback on many (almost all) variables so we can monitor variable state.
We also register a few separate action callbacks that run a different Python function when a particular variable is changed.
This all works fine and we can run experiments on three clicks: start the Client, load the variable set, press start.
However if we start streaming to a file, it looks like the callback we registered is no longer getting called when the variable changes state.
One Server message interposed between file streaming and the error is “MWServer: Received new codec, updating variable registry”. Does this erase all the registered callbacks so we’d need to re-register them? That seems consistent, because if we restart the client bridge, it re-registers the callbacks and things work fine.
If this isn’t an easy thing to solve, we can set up a Zoom call and walk you through it, perhaps, replicating it so you can see what is happening.
I’m away on vacation next week and back week of Aug 27. cc:ing Nina and Connor, they’re around that week too.
If your Python code registers multiple callbacks for any given variable (which it sounds like it does, in the case of the separate action callbacks), then when a new codec is received (which, as you note, happens when you open an event file), only the most-recently-registered callback for each variable will remain active. This is a bug that should be trivial to fix, but it will require a change in C++ code, so you’ll need to update to a new MWorks build to take advantage of it.
To work around the issue, you could register the separate action callbacks by code, rather than by name. That is, replace
Alternatively, if you’re registering callbacks on most variables just to track their values, you could handle that with a single callback registered via conduit.register_callback_for_all_events, or you could use a CachingIPCClientConduit.
I had some time today so I switched our client bridge code over to use the CachingIPCClientConduit. It seems to work fine.
Nina, Connor, this should make things work more smoothly especially on slow rig machines. You should test it on the test rig and maybe one of the rig machines. The code is on the 2408/pyclientcacheconduit branch. Then we can merge and roll out to all the rigs.