Closed certabitmh closed 4 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)?
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?
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...
how are you setting ConfigCommon::mqtt_command_timeout?
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));
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?
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.
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.
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