Closed BlackstoneEngineering closed 7 years ago
Has anyone else seen this? @bridadan @DougAnsonAtARM @janjongboom @yogpan01
ARM Internal Ref: IOTCLT-610
Never had a device running so long myself.
@BlackstoneEngineering We have had these long running cases here and we also see device dropping off, as you already mentioned possible causes being there is no re-connection logic on example application, there is strong probablity that any kind of network hiccups will cause it to drop of, which will then require some re-trial logic implemented on example application end. Having said that we do have an error open for this specific problem, internally IOTSVS-633
@janjongboom Can we add some basic reconnect / reset code to this example then? This is supposed to be a piece of 'golden' code that others will clone and modify. If we can fix it here we can save ourselves alot of trouble down the road.
Issue should be resolved. Re-open if it exists in new implementation (https://github.com/ARMmbed/mbed-os-example-client)
We have long-running CI-tests can easily pass 24 hour mark. Of course, using UDP in open internet will never work very reliable, so UDP only via VPN-pipe or then use TCP for anything that has to stay online without hickup. Also Client has the reconnection-logic implemented probably after this ticket was opened.
I am seeing a consistent error where the example program will stop being seen by connector after 24 hours. Not sure if this is a bug in the embedded code where its DHCP expires and it simply needs to re-register, or if its a connector bug, or if its something inside the mbed client code. Raising it as an issue for further investigation.