2012-11-02 10 views
13

Ich kann keine geeignete Lösung für dieses Problem finden. Ich denke, jemand kann mir helfen, diesen Fehler zu beheben. purgeIdleCellConnections: gefunden zu spülen conn = 0x1ddde360

Zusammenfassung: Wenn ich eine 3G-Verbindung verwenden, um meine App auf dem Gerät zu testen, durch die Zeit, die Konsole diesen Fehler zeigt "purgeIdleCellConnections: found one to purge conn = 0x1ddde360" mehr als einmal, kommt es mit einer unterschiedlichen Anzahl (0x1ddde360 or 0x21b98a60 or....). Manchmal hängt es und die Anwendung stürzt ab und stirbt. Ich kann die App nicht öffnen. Ich muss löschen und neu aufbauen. Wenn ich Wi-Fi verwende, funktioniert es gut: überhaupt kein Problem.

Aktuelle Ergebnisse: Ich verwende einen Webdienst (WSDL) in meiner App. Während ich die Anwendung selbst starte, rufe ich mehr als einen Webservice an. Diese App ist bereits im App Store (Promayarnlite), aber diese Datei wurde mit dem IOS 5.1 SDK erstellt, so dass es gut funktionierte. Jetzt habe ich meinen Xcode auf 4.5.1 und IOS 6 SDK aktualisiert, also möchte ich meine App im App Store aktualisieren. Ich kämpfe mit diesem Teil.

BEARBEITEN: A: Intern verwaltet NSURLConnection einen Verbindungscache. Jeder Cache-Eintrag repräsentiert eine Menge persistenter HTTP-Verbindungen zu einem Host. Wenn eine neue Anforderung eingeht, wird sie für einen Eintrag im Cache in die Warteschlange gestellt. Dies kann ein bestehender Eintrag oder ein neuer Eintrag sein, und es kann auch eine neue HTTP-Verbindung innerhalb dieses Eintrags generiert werden, abhängig von verschiedenen komplexen Faktoren (der Schutzbereich, der Authentifizierungsstatus [im Falle von Authentifizierungsmethoden - ja , Ich sehe dich an, NTLM! - das sind Stateful], Pipelining, verschiedene Cache-Grenzen, und so weiter). Wenn eine Verbindung, die mit einem Cache-Eintrag verknüpft ist, alle ihre Anforderungen beendet, sucht sie nach weiteren Arbeiten an der Warteschlange des Cache-Eintrags. Wenn es nicht gefunden wird, geht die Verbindung in den Leerlauf. Wenn die Verbindung zu lange inaktiv ist, wird die Verbindung gelöscht (wodurch die zugrunde liegende TCP-Verbindung geschlossen wird).

Diese Cache-Implementierung hat sich in iOS 6 geändert. Vor iOS 6 gab es einen Mechanismus zum Löschen leerer Cache-Einträge mit grundlegend unterschiedlichen Timeouts für Mac OS X und iOS (30 Sekunden vs. 6 Sekunden) bei älteren iOS-Versionen mindestens 3 Sekunden lang sein). In iOS 6 gibt es jetzt zwei Mechanismen zum Löschen leerer Cache-Einträge, eine für Verbindungen, die über WWAN laufen, und eine, die für alle anderen Verbindungen gilt. Das WWAN-Zeitlimit ist auf den Standardwert (3 Sekunden) zurückgegangen, während das Zeitlimit für alle anderen Verbindungen auf den alten Standard von Mac OS X (30 Sekunden) gesetzt wurde.

Die Protokollnachricht, die Sie sehen, wird generiert, wenn eine WWAN-Verbindung gelöscht wird. Diese Protokollnachricht war in iOS 5.x nicht vorhanden. Dies erklärt, warum sie in Ihren Tests nicht angezeigt wird. Der grundlegende Mechanismus ist jedoch in der einen oder anderen Form in allen Versionen von iOS vorhanden.

Diese Nachricht ist eher ein Symptom als eine Ursache. Insbesondere gilt die Nachricht nur für inaktive Verbindungen; Dies ist nur NSURLConnection bereinigt persistente HTTP-Verbindungen, die nichts nützliches tun. Wenn Sie Probleme mit Ihrem Netzwerk haben, müssen Sie untersuchen, warum die Verbindungen inaktiv sind.

+4

https://developer.apple.com/library/ios/#qa/qa1774/_index.html#//apple_ref/doc/uid/DTS40012992 – fellowworldcitizen

+0

mögliches Duplikat von [cleanIdleCellConnections: gefunden, um conn = 0x1d57ba00 zu löschen] (http://stackoverflow.com/questions/14754828/purgeidlecellconnections-found-one-to-purge-conn-0x1d57ba00) –

Antwort

0

Wenn auf dem Gerät mit dem Mobilfunknetz verbunden ist, habe ich beobachtet, diese Debug-Nachricht aus dem iOS 6.0 SDK kommt. Timing-weise finde ich es korreliert mit "aktiven" AJAX-Anrufe in meiner App beendet werden. Es ist jedoch sehr schwierig, etwas zu beweisen, da dies nur beim Rendern der Webseite in einem UIWebView geschieht. Ich sage nur, ich glaube nicht, dass die Nachrichten gutartig sind. Ich denke, sie könnten auf einen Fehler im Apple-Framework hinweisen, der beim Beenden von Verbindungen zu aggressiv ist. Es ist schwer, Instrumentierung über das Javascript innerhalb des UIWebView zu bekommen, das die AJAX Aufrufe macht, so dass es derzeit alles sehr spekulativ ist.

+2

Hai mr.ED, Apple Developer Technical Support sagt: "Es ist unwahrscheinlich, dass diese Protokollmeldung die direkte Ursache für diese Probleme ist. Wie ich in meiner vorherigen Antwort erwähnt habe, ist das Löschen von WWAN-Verbindungen auf allen früheren Versionen von iOS erfolgt. Der einzige Unterschied ist, dass wir versehentlich gegangen sind in einer unnötigen Log-Nachricht in iOS 6 ". – Abdu

2

Gesehen auf Gerät mit iOS 6.0.1 (iPhone 3GS), wenn Sie AdMob Mediation SDK verwenden. Die Anwendung selbst führt mehr als 100 Verbindungen zum Server aus (die nächste Server-API behebt dieses Problem). Diese Konsolenprotokollmeldungen werden jedoch erst angezeigt, nachdem die AdMob-Verbindungen aktiviert wurden. Sowohl 3G als auch Wifi (10M Verbindung).

Beste Schätzung ist, dass iOS nicht glücklich ist, Netzwerkanrufe von zwei verschiedenen Netzwerkbibliotheken - AdMob in diesem Fall, aber ich denke, es könnte alles sein. Nur ein Zufall.

Manchmal App wird völlig fest, manchmal gibt es keine sichtbaren Probleme. Würde Liebe, das zu beheben, aber bis jetzt nichts gefunden haben ...

Verwandte Themen