purgeIdleCellConnections: found one to purge conn=0x1ddde360
Asked Answered
C

2

13

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.

Connie answered 2/11, 2012 at 10:0 Comment(2)
developer.apple.com/library/ios/#qa/qa1774/_index.html#//…Katzen
possible duplicate of purgeIdleCellConnections: found one to purge conn = 0x1d57ba00Heavyhearted
V
2

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...

Virginity answered 21/11, 2012 at 9:31 Comment(0)
D
0

When on the device connected to cellular network, I have observed this debug message coming out of the iOS 6.0 SDK. Timing-wise I find it correlates to 'active' AJAX calls being terminated in my app. However it is very difficult to prove anything since this only occurs when rendering the web page in a UIWebView. I am just saying I don't think the messages are benign. I think they might indicate a bug in the Apple framework that is overly aggressive in terminating connections. It is hard to get instrumentation on the javascript running inside the UIWebView that makes the AJAX calls, so it is all highly speculative at this time.

Dioptric answered 20/11, 2012 at 21:20 Comment(1)
Hai mr.ED, Apple Developer Technical Support says that "It's unlikely that this log message is the direct cause of these problems. As I mentioned in my previous response, the purging of WWAN connections occurred on all previous versions of iOS; the only difference is that we accidentally left in an unnecessary log message in iOS 6".Connie

© 2022 - 2024 — McMap. All rights reserved.