Petits problèmes de synchronisation depuis iOS 8.x ?
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.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Bon, le problème revient peu après (il faudrait faire un "oublier le réseau" à chaque fois)...
Je vais enquêter.
J'ai ma piste: un bug d'Apple iOS 8 avec AFNetworking !
https://github.com/AFNetworking/AFNetworking/issues/2314
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.
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.
---
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 ?
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.
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.
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...)
J'y vais de ce pas, on sait jamais !
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"
Je pense toujours que ceci est la piste la plus plausible:
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...
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...
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.
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...
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é:
Mais dans le client, j'ai toujours mon "connection: keep-alive", et non "connection:close".
Il n'y a aucune différence excepté le bundle name et le product name.
https://itunes.apple.com/us/app/console/id317676250?mt=8
Apparemment, elle n'est que sur iPhone...
Et le problème est sur l'iPad.
C'est pas grave, ça va fonctionner quand même en mode app x2 sur l'iPad.
Pourquoi installer une appli alors qu'on peut voir la console dans Xcode ?
Merci pour l'info. C'est nouveau ?
Cela reste plus pratique dans quelques cas d'avoir l'app embarquée.
Je crois que ce n'est plus autorisé par Apple.
Oui, mais il n'y a rien.
Je ne vois que des crashs anciens.
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.