Petits problèmes de synchronisation depuis iOS 8.x ?

muqaddar · octobre 2014

J'ai quelques utilisateurs qui ont eu des problèmes pour synchroniser depuis quelques temps (iOS 8 ?)

Mon dernier test ce matin:

- iPad 3 WIFI only: aucun problème

- iPhone 6 WIFI et 4G: ça patine, ça tourne dans le vide, après le "pull".

1) si je désactive le WIFI sur mon iPhone, ça remarche !

2) ce que j'ai fait: j'ai demandé dans les réglages de l'iPhone d'oublier le réseau WIFI, et je me suis reconnecté, et là , ça a marché, même en WIFI...

Si quelqu'un a une explication rationnelle sur l'oubli du réseau WIFI et la reconnexion... j'avais regardé ce qu'il se passait sur les logs du serveur et il renvoyait bien les réponses après le premier "pull"...

Etrange.

muqaddar · octobre 2014

Bon, le problème revient peu après (il faudrait faire un "oublier le réseau" à chaque fois)...

Je vais enquêter.

muqaddar · octobre 2014

J'ai ma piste: un bug d'Apple iOS 8 avec AFNetworking !

https://github.com/AFNetworking/AFNetworking/issues/2314

AliGator · octobre 2014

Ou plutôt un bug Apple sur iOS8 avec les connections POST en Keep-Alive. AFNetworking ou pas n'y changera rien.

muqaddar · octobre 2014

Ou plutôt un bug Apple sur iOS8 avec les connections POST en Keep-Alive. AFNetworking ou pas n'y changera rien.

C'est exactement ça.

C'est un bug énorme, bizarre que l'on entende pas plus parler.

Pour l'instant, je me bas avec mon Nginx pour désactiver temporairement keep-alive.

muqaddar · novembre 2014

Le retour de la vengeance.

Je pensais avoir éradiqué ce bug. Il refait surface...

Déjà , le bug ce produit aussi en GET et pas seulement en POST.

Ensuite, voilà de quoi rendre chèvre:

1) A chaque fois que je lance la synchronisation après plusieurs heures, pas de soucis en général.

2) C'est la fois suivante (même quelques minutes après) que la requête "tombe dans l'oubli".

3) Supprimer l'application en mémoire et la relancer permet de synchroniser à nouveau.

4) Il n'est que sur iOS 8.x (ou est-il revenu avec iOS 8.1.1... ?), je n'avais pas eu de retour depuis 2 mois.

5) Je n'ai pas le bug sur mon iPhone 6, mais sur mon iPad 3, or c'est le même moteur...

6) Pire: j'ai le bug sur ma version distri 2.6, mais je n'arrive pas à le reproduire sur ma version debug 2.6 sans aucun changement dans le code !!! Sur ma version debug, je peux lancer 10 synchros à la suite avec succès. Sur la version distri, 1 seule.

Il n'y a rien qui diffère entre les 2 dans les logs du serveur.

Du coup, je ne peux même pas débuguer ma version debug, puisqu'elle n'a pas le problème !

Et je ne suis même pas sûr que ce soit la source du problème au final:

https://github.com/A...ing/issues/2314

7) La dernière fois, c'était un problème lié au WIFI et le désactiver marchait.

Or sur mon iPhone 6, si je désactive les données cellulaires, ça marche quand-même (wifi only).

8) L'utilisateur qui a le même problème a un iPad 2, p-e est-ce lié uniquement aux "vieilles" tablettes.

---

FKDEV · novembre 2014

1+2+3+6 me font penser à un problème de mémoire. Quelque chose reste de la précédente synchro. La piste de la connexion qui reste disponible alors qu'elle ne le devrait pas me parait bonne.

Comment avais tu fait pour faire "disparaitre" le probleme ?

muqaddar · novembre 2014

Je suis sûr à 99% que ce n'est pas un problème de mémoire.

Au fait, j'ai oublié de signifier qu'évidemment, la synchro avait lieu avec le même ID et la même base entre la debug et la release.

L'histoire du keep-alive est toujours plausible... mais plus celle du WIFI.

Pour l'instant, je n'ai qu'un utilisateur qui m'a rapporté le problème, mais j'ai le même comportement que lui.

Pour faire disparaà®tre le problème, j'avais supprimé des vieux "nsthread with time inverval de 1 seconde" qui traà®naient dans ma synchro (pour définir les étapes à l'utilisateur). Une histoire de délai entre les requêtes donc...

Enfin, je ne suis jamais arrivé à ne pas avoir de keep-alive avec nginx malgré les modifs de ma conf. Et pourtant, pas eu de problème pendant 1 mois.

muqaddar · novembre 2014

Quelques infos supplémentaires.

Quand ça marche, j'ai dans l'ordre des requêtes:

- login POST

- pull GET

- pull_items POST

Quand ça ne marche pas

- login POST

- pull GET

... et la dernière API pull_items n'est jamais appelée sur le serveur. iOS doit essayer de recycler une connection foireuse.

muqaddar · novembre 2014

Et vous voulez encore du plus étrange ?

Mon ancienne beta 2.6 marche sans problème, c'est l'exacte réplique de la version actuellement en vente. Je peux envoyer X synchros à la suite sans soucis.

Donc :

Debug: OK

Beta: OK

Distri: KO (après première synchro...)

Draken · novembre 2014

T'as fais la mise à jour de ta poupée vaudou ?

muqaddar · novembre 2014

T'as fais la mise à jour de ta poupée vaudou ?

J'y vais de ce pas, on sait jamais !

FKDEV · novembre 2014

Comment est compilé ta beta ? Meme build settings que la version finale ?

Je disais probleme memoire car quelque chose se reinitialise mal apres la premiere synhro.

En tant que client http tu peux demander à ne pas avoir de keep alive http.

"connection: close"

muqaddar · novembre 2014

Je pense toujours que ceci est la piste la plus plausible:



This is an issue with the underlying HTTP implementation of NSURL.

As far as we can tell, when iOS 8 receive an HTTP response with a Keep-Alive header, it keeps this connection to re-use later (as it should), but it keeps it for more than the timeout parameter of the Keep-Alive header and then when a second request comes it tries to re-use a connection that has been dropped by the server.

Pour un problème mémoire, pourquoi il ne serait pas présent en debug et beta ? Je n'y crois pas. Enfin, ça dépend ce que t'appelles problème mémoire.

Je n'arrive pas à obtenir le "keep-alive:close" justement...

muqaddar · novembre 2014

Vous en voulez une autre de bonne ?

Ce matin, je peux lancer 5 synchros sans soucis sur la version Distri. >:D

Même si c'était un problème serveur, pourquoi ne pas l'avoir sur la version Beta et Debug hier soir ?

--

Edit: retour du bug à la 6è ou 7è synchro...

FKDEV · novembre 2014

Le http header "Connection: Close" peut être mis côté serveur ou côté client.

Je ne sais pas si iOS et/ou AFNetworking permettent de le faire cependant, j'ai trouvé des vieux posts qui indiquent que non, mais c'est à tester.

Tu as les sources de AFNetowrking, donc tu peux toujours forcer ce header juste avant d'envoyer pour tester si cela corrige le problème et si cela n'est pas overridé par iOS.



NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url

cachePolicy:NSURLRequestUseProtocolCachePolicy

timeoutInterval:60.0];



[request addValue:@close forHTTPHeaderField:@Connection];

FKDEV · novembre 2014

C'est quoi le "bug" exactement ? Y'a un message d'erreur ? une exception ?

muqaddar · novembre 2014

C'est quoi le "bug" exactement ? Y'a un message d'erreur ? une exception ?

La synchro ne se finit pas. Elle tourne dans le vide. (barre de progression non remise à zéro).

Comme je disais, il ne se passe rien après la 2è méthode : pull() est exécuté sur le client, mais pull-items() n'est jamais exécuté sur le serveur, soit iOS bazarde la requete, soit le serveur...

Mais comme je ne peux pas débuguer la version distri...

muqaddar · novembre 2014

Le http header "Connection: Close" peut être mis côté serveur ou côté client.

Je ne sais pas si iOS et/ou AFNetworking permettent de le faire cependant, j'ai trouvé des vieux posts qui indiquent que non, mais c'est à tester.

Tu as les sources de AFNetowrking, donc tu peux toujours forcer ce header juste avant d'envoyer pour tester si cela corrige le problème et si cela n'est pas overridé par iOS.
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url

cachePolicy:NSURLRequestUseProtocolCachePolicy

timeoutInterval:60.0];



[request addValue:@close forHTTPHeaderField:@Connection];

C'est là tout le problème, comment savoir si c'est le problème puisque ma version debug marche déjà ...

Sur le serveur, j'utilise nginx:

http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_disable

J'ai ajouté:



        keepalive_disable safari;

        keepalive_timeout 0 0;

        keepalive_requests 1;

Mais dans le client, j'ai toujours mon "connection: keep-alive", et non "connection:close".

muqaddar · novembre 2014

Comment est compilé ta beta ? Meme build settings que la version finale ?

Il n'y a aucune différence excepté le bundle name et le product name.

FKDEV · novembre 2014

as tu installé l'app console sur ton device pour voir si des traces sont générées par les API dans ta version distri ?

https://itunes.apple.com/us/app/console/id317676250?mt=8

muqaddar · novembre 2014

Apparemment, elle n'est que sur iPhone...

Et le problème est sur l'iPad.

FKDEV · novembre 2014

C'est pas grave, ça va fonctionner quand même en mode app x2 sur l'iPad.

Céroce · novembre 2014

Pourquoi installer une appli alors qu'on peut voir la console dans Xcode ?

FKDEV · novembre 2014

Merci pour l'info. C'est nouveau ?

Cela reste plus pratique dans quelques cas d'avoir l'app embarquée.

muqaddar · novembre 2014

C'est pas grave, ça va fonctionner quand même en mode app x2 sur l'iPad.

Je crois que ce n'est plus autorisé par Apple.

muqaddar · novembre 2014

Pourquoi installer une appli alors qu'on peut voir la console dans Xcode ?

Capture d'écran 2014-11-25 à 09.12.02.png

Oui, mais il n'y a rien.

Je ne vois que des crashs anciens.

Céroce · novembre 2014

Merci pour l'info. C'est nouveau ?

Je sais que la Console était déjà présente dans Xcode 5, mais il y a peut-être eu une période pendant laquelle Xcode 6 ne la proposait plus.

Petits problèmes de synchronisation depuis iOS 8.x ?

Réponses