purgeIdleCellConnections: found one to purge conn=0x1ddde360

Question

I cannot find a proper solution to this problem. I think someone can help me to clear this bug.

Summary: When I use a 3G connection to test my app on the device, by the time the console shows this bug "purgeIdleCellConnections: found one to purge conn = 0x1ddde360" more than one time, it occurs with different number (0x1ddde360 or 0x21b98a60 or....). Sometimes it hangs and the application crashes and dies. I cannot open the app. I have to delete and build again. When I use Wi-Fi it works fine: no problem at all.

Actual Results: I am using a web service(WSDL) in my app. While launching the application itself I am calling more than one web service. This app is already in the App Store (Promayarnlite) but that file was built using the IOS 5.1 SDK so it worked fine. Now I updated my Xcode to 4.5.1 and IOS 6 SDK, so I want to update my app in the App Store. I am struggling with this part.

EDIT: A: Internally NSURLConnection maintains a connection cache. Each cache entry represents a set of persistent HTTP connections to a host. When a new request comes in, it is queued on an entry in the cache. This may be an existing entry or it may be a new entry, and it may also generate a new HTTP connection within that entry, depending on various complex factors (the protection space, the authentication status [in the case of authentication methods--yes, I'm looking at you, NTLM!--that are stateful], pipelining, various cache limits, and so on). When a connection associated with a cache entry finishes running all of its requests, it looks for more work on the cache entry's queue; if it doesn't find any the connection goes idle. If the connection is idle for too long, the connection is purged (which closes the underlying TCP connection).

This cache implementation has changed in iOS 6. Prior to iOS 6 there was a single mechanism for purging idle cache entries, with radically different timeouts for Mac OS X and iOS (30 seconds versus 6 seconds, and the iOS value could be as low as 3 seconds on older versions of iOS). In iOS 6 there are now two mechanisms for purging idle cache entries, one that applies to connections running over WWAN and one that applies to all other connections. The WWAN timeout has dropped back to its traditional value (3 seconds) while the all-other-connections timeout has been bumped up to the old Mac OS X default (30 seconds).

The log message you're seeing is generated when a WWAN connection is purged. This log message didn't exist in iOS 5.x, which explains why you're not seeing it in your tests. However the basic mechanism has been present, in one form or another, on all versions of iOS.

This message is more likely to be a symptom than a cause. Specifically the message only applies to idle connections; this is just NSURLConnection cleaning up persistent HTTP connections that aren't doing anything useful. If you're having problems with your networking you need to investigate why the connections are going idle.

Answer 1

Seen this on device running iOS 6.0.1 (iPhone 3GS), when using AdMob Mediation SDK. Application itself does 100+ connection to server (next server API will fix that issue), but these console log messages started appearing only after AdMob connections got active. Both 3G and Wifi (10M connection).

Best guess is that iOS is not happy getting network calls from two different networking libraries - AdMob in this case, but I guess it could be anything. Just a coincident.

Sometimes app gets totally stuck, sometimes there's no visible problems. Would love to fix this, but so far haven't found anything...