Je me battais ce problème toute la journée et j'ai besoin d'une contribution.
J'ai une demande de rails (3.1.3) en cours d'exécution sur Heroku Cedar, essayant de publier des actions de graphes ouvertes sur Facebook avec Gem FB_Graph ( 2.4.0). P>
Ceci est mon code. P> si je vais à la page de mon application qui tentera d'exécuter ce code, va échouer avec le message suivant. P> FbGraph::InvalidRequest (Exception :: Could not retrieve data from URL.)
3 Réponses :
Le lien suivant semble suggérer qu'il s'agit d'un délai d'attente liée, bien qu'aucune solution réelle n'a encore été donnée. facebook "could not retrieve data from URL"
Vous pouvez également garder une trace des réponses pour le lien ci-dessus.
Merci pour le lien. Bon de voir que je ne suis pas seul. Je ne suis pas sûr de la chose du délai d'attente. Il faut ~ 400ms pour rendre la page Game_url. Cela ne devrait pas cas de dépistage juste? Mérite d'enquêter. Merci.
résolu!
vraiment stupide en fait. Je n'avais qu'un seul dyno Web dans mon application Heroku. Étant donné que mon seul web dyno faisait l'appel de l'API Facebook, il n'y avait pas de dyno pour répondre au rappel Facebook. Vous avez besoin d'au moins 2 pour que cela fonctionne.
La raison pour laquelle le code a fonctionné dans la console Heroku était simplement parce que le Web Dyno n'était pas occupé à gérer ma demande.
Je pourrais pousser ce code à une file d'attente de travail à l'avenir, car il semble plus approprié et laisser un travailleur dyno gérer la publication Facebook.
Notez que, même avec deux DYNOS, vous pouvez toujours bloquer si le routeur envoie la demande au mauvais dyno. J'ai suggéré que la licorne dans une autre réponse; Une autre alternative consiste à utiliser une deuxième application pour implémenter le rappel, bien que je ne sois pas sûr si la gemme FB_Graph est susceptible de fonctionner.
@metadaddy, Heroku dit que plus d'un dyno fournit plus de concurrence. Si j'ai deux dynos, pourquoi est-ce un routage vers le même dyno? Quel routeur envoie au mauvais dyno?
@Tony, la couche de routage distribuera des demandes sur vos dynos. Disons que vous avez 2 DYNOS, et DYNO 1 traite la demande décrite ci-dessus. Une seconde demande arrive (à partir du navigateur de certains utilisateurs, pas de FB) et est acheminé vers Dyno 2. La demande arrive maintenant de FB et pourrait bien être acheminée vers Dyno 1, qui induit l'impasse. L'ajout d'un dyno convient à des tests, mais ce n'est pas une solution solide à plus long terme.
@metaDADDY, même avec 5 DYNOS, le rappel Facebook a été envoyé au même Dyno que la demande initiale. Est-ce que tu sais pourquoi?
@Tony, intéressant - j'ai souvent configuré plusieurs dynos sur une application Rails, puis actualisez la page de mon navigateur plusieurs fois et voir les demandes distribuées à travers les Dynos. Je ne sais pas pourquoi vous voyez ce comportement. Vous devriez demander à support.heroku.com
Merci. Si je fais ce que vous me dites, je peux voir les demandes distribuées à travers les Dynos, mais sur le cas spécifique du rappel FB, il utilise le même dyno que la demande d'origine, de sorte qu'il soit bloqué.
J'ai résolu le problème qui change la pile de Heroku en Cedar et en utilisant Unicor Server. Je me demande toujours pourquoi il n'a pas fonctionné avec plusieurs dynos.
Une alternative à un second dyno pourrait être d'essayer Unicorn - Cela permettrait à votre application de servir la seconde appeler tandis que le premier est bloqué.
Ces articles donnent des détails utiles sur la démarrage avec Unicorn:
Avez-vous essayé de changer env ['facebook_app_id'] et y compris l'identifiant juste là-bas? J'ai eu des problèmes avec les variables Facebook et Environnement auparavant.
Cela valait la peine d'essayer, mais tristement aucun effet. J'ai aussi essayé d'ajouter le secret, même si cela ne devrait pas être nécessaire.
Mise à niveau FB_Graph vers la version 2.4.7 sans effet.