Hi I’m doing some development with a Xavier NX and Deepstream 5.0 connecting modules up to Azure using nvmsgbroker and I’ve got a segmentation fault in my code after an hour or so where I’m being called back by libnvds_azure_edge_proto upon successfully (I hope) sending a message to Azure IOT Hub using a shared connection handle obtained from nvmsgbroker (which the docs say is OK to do). I’m using the new api, rather than legacy.
It would help very much if I could get a full backtrace with GDB but I’ve no way of compiling libnvds_azure_edge_proto with symbols. Also libnvds_azure_edge_proto spits out every message over stdout in the iotedge module log and given this module creates over a million of these per day I’d really like the option of switching them off.
I’ve looked around and there doesn’t seem to be any link to the source code for libnvds_azure_edge_proto, and the place I’d expect it to be in the deepstream sdk just has some test code.
Is there any reason this source code is not released?
Thanks for the answer. Can I ask that you pass on that this might be reconsidered? As I point out, the default behavior of this library is to write every message sent to stdout which gets put into iotedge logs on the device. For millions of messages each day this is a stress on the SD card. Having source would enable me to disable this.
Also, I don’t understand why it is closed - the libraries above and below it in the hierarchy are open and since the kafka version is available, I’m not seeing what proprietary methods are needed to be kept secret.
So open-sourcing hasn’t happened yet and I just encountered another problem.
As far as I can tell the msgbroker library (closed source) is not setting the message headers for Azure to “utf8” and “application/json”. The consequence of this is that if messages are stored in blob containers they are encoded and not easy to read. Even more importantly, it’s impossible to set a rule at the IOT hub to route messages based upon the body since the body can’t be decoded by the IOT hub. This prevents a lot of use cases.
See here for more details:
This is making my debugging and development very difficult. Is there any ETA on this? Or even a fix? I really don’t want to modify the IOT client SDK to force json and utf-8 as I may want to use the client SDK elsewhere to other types of objects.
Of course, I’d be even happier if I’m mistaken and it’s an error in my code somewhere.