Too many bugs like memory leaks or cpu usage too high.

[MrLiuYunPing]

To help us solve your problem better, please answer the following list of questions.

• What service are you using? Iot
• In what version of SDK are you facing the problem? 2.6.21
• Is the issue limited to Simulators / Actual Devices? NO
• Can your problem be resolved if you bump to a higher version of SDK? NO
• Is this problem related to specific iOS version? NO
• How are you consuming the SDK? CocoaPods / Carthage / Prebuilt frameworks? CocoaPods
• Can you give us steps to reproduce with a minimal, complete, and verifiable example? Please include any specific network conditions that might be required to reproduce the problem. Too many bugs like memory leaks or cpu usage too high. Memory leaks in runtime when reading .p12 method and other methods. When network is lost,mqtt reconnection will make cpu usage too high in about 3 second time.

If you need help with understanding how to implement something in particular then we suggest that you first look into our developer guide. You can also simplify your process of creating an application by using Mobile Hub.

[scb01]

@MrLiuYunPing

Sorry to hear that you are running into issues. To help debug this further, can you provide a code snippet, logs and stacktraces if possible

[sangios]

Dear all,

The case that after connects MQTT successfully, you will see CPU usage too high when turns off wifi, or in airplane mode, or no internet connection.

while (self.runLoopShouldContinue in - (void)openStreams:(id)sender of AWSIoTMQTTClient.m never exits. Also "[runLoopForStreamsThread runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];" without input source will make cpu too high.

PODS:

• Alamofire (4.7.2)
• AWSCore (2.6.22)
• AWSIoT (2.6.22):
  • AWSCore (= 2.6.22)

[scb01]

@sangios I tried to reproduce this issue on my side by running instruments on a iPhone 5s, iOS 9.3.5 and did not see the high CPU usage. Would be great if you could provide details on how you are observing this to help me reproduce it so that I can debug the issue.

The while loop in the openStreams method runs as long as the runLoopShouldContinue instance variable is set to YES. This run loop handles MQTT messages and will continue to be executed each time there is a message to be sent, to be received or a timer event to be handled. The runLoopShouldContinue variable is set to false in another thread when a disconnect ( see the disconnect method in the same class) is issued to the client which causes the while to exit.

My understanding of runloops is that a runloop will exit if there are no input sources/timers scheduled on it (see https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html#//apple_ref/doc/uid/10000057i-CH16-SW4 ). Can you please provide some more details/share some info on your point about the CPU being too high due to the runloop.

This may be a moot point - in the SDK architecture, this run loop always has multiple input sources and timers scheduled on it.

[sangios]

@cbommas "My understanding of runloops is that a runloop will exit if there are no input sources/timers scheduled on it " -> I agree with you, but runLoopShouldContinue is not set to NO, so this will make make cpu too high due to no source input. I think you should added a NSDate to check the loop condition. Never trust runLoopShouldContinue.

[scb01]

@sangios

While I haven't been able to reproduce the high CPU situation, I have made some tweaks to the runloop code as per your reccomendation. I have replaced the [NSDate distantFuture] with [NSDate dateWithTimeIntervalSinceNow:10]. So each cycle of the run loop will exit after 10 seconds if no event was received.

Also, I added an additional timer to the runloop to make sure that there is always a Timer attached to the runloop. That should prevent it from exiting immediately during a reconnect sequence if (depending on the timing of the threads) there are no input sources or timers attached to the run loop.

These changes will be available in the next rev of the SDK. I will loop back on this thread once the next rev is out.

[scb01]

@sangios @MrLiuYunPing

Version 2.6.23 was released yesterday ( july 5) and contains the changes for this issue. Please upgrade to this version and let me know how it goes.

[scb01]

@sangios @MrLiuYunPing

Closing this issue as I haven't heard back. Please feel free to reopen if necessary.