Error while trying to run blob upload from MQTT client sample

[jakuboz]

• OS and version used: Raspbian Stretch 4.9.41-v7+ OPTION_DO_WORK_FREQUENCY_IN_MS #1023

• SDK version used: 1.1.26

Description of the issue:

I've tried to combine two samples thogether- iot_hub_client_sample_mqtt and iot_hub_client_sample_upload_to_blob. After receiving a message from Cloud program should upload a blob to a storage.
While- when run separately- samples work fine (small exception below), after simply copy-pasting them together and running gives me an error.
Only modification to my environment is mentioned here: #219 (comment) - I've replaced openssl with libcurl4-gnutls-dev

Code sample exhibiting the issue:

Complete source code is available on my github.
https://github.com/jakuboz/iot_hub_sdk_sample
I've tried not to modify the samples much, only appropriate connection strings are needed to run the sample.
First I thought that issue was caused by running both activities in a single thread (running both samples simultaneously works) hence the threadFunc in (...)upload_to_blob but this seems not to be the issue.
Lines 95 and 96 in (...)sample_mqtt.c can be used alternatively.

Repro steps:

1. Add appropriate connection strings to iothub_client_sample_mqtt.c (line 28) and iothub_client_sample_upload_to_blob.c (line 32)
2. Build and run sample
3. Send "test" as a message to device

Console log of the issue:

Info: IoT Hub SDK for C, version 1.1.26
IoTHubClient_LL_SetMessageCallback...successful.
-> 12:35:29 CONNECT | VER: 4 | KEEPALIVE: 240 | FLAGS: 192 | USERNAME: (...) | PWD: XXXX | CLEAN: 0
<- 12:35:29 CONNACK | SESSION_PRESENT: true | RETURN_CODE: 0x0
-> 12:35:29 SUBSCRIBE | PACKET_ID: 2 | TOPIC_NAME: (...) | QOS: 1
<- 12:35:29 SUBACK | PACKET_ID: 2 | RETURN_CODE: 1
<- 12:35:40 PUBLISH | IS_DUP: false | RETAIN: 0 | QOS: DELIVER_AT_LEAST_ONCE = 0x01 | TOPIC_NAME: (...) | PACKET_ID: 26 | PAYLOAD_LEN: 4
Received Message [0]
 Message ID: <null>
 Correlation ID: <null>
 Content-Type: <null>
 Content-Encoding: <null>
 Data: <<<test>>> & Size=4
Error: Time:Tue Oct 31 12:35:40 2017 File:/home/pi/azure-iot-sdk/c-utility/src/tlsio_openssl.c Func:openssl_static_locks_install Line:488 Locks already initialized
Error: Time:Tue Oct 31 12:35:40 2017 File:/home/pi/azure-iot-sdk/c-utility/src/tlsio_openssl.c Func:tlsio_openssl_init Line:1016 Failed to install static locks in OpenSSL!
Failed to initialize the platform.
<- 12:35:52 PUBLISH | IS_DUP: false | RETAIN: 0 | QOS: DELIVER_AT_LEAST_ONCE = 0x01 | TOPIC_NAME: (...)| PACKET_ID: 27 | PAYLOAD_LEN: 4
Received Message [1]
 Message ID: <null>
 Correlation ID: <null>
 Content-Type: <null>
 Content-Encoding: <null>
 Data: <<<quit>>> & Size=4
iothub_client_sample_mqtt has gotten quit message, call DoWork 3 more time to complete final sending...
-> 12:35:52 DISCONNECT

If not direct help, then push in the right direction would be much appreciated, as I've already run out of ideas.

[markrad]

Hi @jakuboz,

I took a look at your code. Are you using the same connection string in both the MQTT half and the Upload half? If you are then your original connection will be terminated by the service when you attempt to connect again. You need to share the IoTHub Client handle between the two.

Mark Radbourne MSFT

[jakuboz]

I've tried using (with the same host name):

• the same connection string
• the same device ID but different access key
• different devices and access keys
  These three don't work with the same output as shown in console log.
  Nevertheless- sharing IoTHub Client handle works like a charm. Thank you very much for your help.

P.S.
Using the same connection string while running these two samples simultaneously from azure-iot-sdk/cmake/iothub_client/samples does not cause any connection termination.

[markrad]

Hi @jakuboz,

You may not see connection termination because the MQTT connection is performed lazily. It does not connect until you call DoWork. Since you don't do that in the file upload portion of the code the MQTT service is likely not aware that you are connecting twice hence you do not see the disconnection. However, the file upload service will be confused because it will be aware of the other connection with the same device name.

I would, however, expected your third scenario, different devices and access keys to have worked. To the Azure IoT hub you would have appeared as two separate devices. I may need to take a look at that.

I've closed your issue. If you still have problems then feel free to reopen it or create a new issue.

Mark Radbourne MSFT