aws / aws-iot-device-sdk-cpp

SDK for connecting to AWS IoT from a device using C++
http://aws-iot-device-sdk-cpp-docs.s3-website-us-east-1.amazonaws.com
Apache License 2.0
123 stars 111 forks source link

MqttClient::Connect ignores action timeout and blocks #118

Closed certabitmh closed 4 years ago

certabitmh commented 6 years ago

Hello,

When calling (Mqtt) Client::Connect(), it blocks the application (as described in doc -> ok) but ignores action timeout. Tried with default ConfigCommon::mqtt_commandtimeout of 20000msecs and reduced of 3000ms.

[https://github.com/aws/aws-iot-device-sdk-cpp/blob/master/src/mqtt/Client.cpp]

I'm using release 1.4.0

certabitmh commented 6 years ago

seems that it's related to timing, if I set the timeout to 10 (should be msec) then Connect returns after somewhat 20 sec... do I have to adjust any timing methods to my platform (arm + emb. linux)?

graebm commented 6 years ago

I'm not seeing the behavior you're describing. I ran the pub-sub-sample on an OSX machine. I set mqtt_command_timeout_msecs to 3000 in SampleConfig.json. Connect() returned after 3 seconds with a timeout error. I tried setting it to 10 and the timeout happened immediately.

Digging into the implementation, the code which holds up the main thread for N milliseconds is this line: aws-iot-device-sdk-cpp/src/ClientCoreState.cpp line 123 It's a call to std::condition_variable::wait_for() and the wait time is passed as std::chrono::milliseconds. That's all standard library stuff. I hope it's implemented correctly on Arm Embedded Linux.

Are you sure that you're actually changing ConfigCommon::mqtt_command_timeout_? Can you set a breakpoint and confirm? Or print out its value?

certabitmh commented 6 years ago

Hi graebm, yes I directly used different values as function paramter of connect instead of ConfigCommon::mqtt_command_timeout and placed the execution in an own thread to ensure nothing else blocks it...

JonathanHenson commented 6 years ago

how are you setting ConfigCommon::mqtt_command_timeout?

certabitmh commented 6 years ago

by directly passing the timeout parameter (2000 or other values) when calling connect:

rc = _pMqttClient->Connect(2000, ConfigCommon::is_clean_session_, mqtt::Version::MQTT_3_1_1, ConfigCommon::keep_alive_timeout_secs_, std::move(client_id), nullptr, nullptr, std::move( p_will_options));

JonathanHenson commented 6 years ago

My impression is that passing the timeout value directly is working for you. Is this the case?

If so, how were you setting the ConfigCommon::mqtt_command_timeout value?

certabitmh commented 6 years ago

NO it doesn’t work. In only changed it by hand to see if lower timeouts (2 instead of 20sec) show any impact on behavior.

As stated, it takes way longer than 2 seconds until connect returns. About factor 10-20 I would say.

So That’s why my question is how time measurement for determining timeout inside connect function could be influenced by any environmental conditions... It’s definitely not blocked by other stuff since it runs in separate thread.

Am 05.09.2018 um 18:43 schrieb Jonathan M. Henson notifications@github.com<mailto:notifications@github.com>:

My impression is that passing the timeout value directly is working for you. Is this the case?

If so, how were you setting the ConfigCommon::mqtt_command_timeout value?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/aws/aws-iot-device-sdk-cpp/issues/118#issuecomment-418799464, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AlquzW22woNo7eBhLdoczUXMPmu2pI5fks5uX_8zgaJpZM4WM1KH.

github-actions[bot] commented 4 years ago

Greetings! Sorry to say but this is a very old issue that is probably not getting as much attention as it deservers. We encourage you to check if this is still an issue in the latest release and if you find that this is still a problem, please feel free to open a new one.