SystemExit fréquentes dans Ruby lors des appels HTTP

voix
18

J'ai un site Web Ruby on Rails qui effectue des appels HTTP à un service Web externe.

Environ une fois par jour, je reçois une erreur SystemExit (stacktrace ci-dessous) email où un appel au service a échoué. Si je tente alors exactement la même requête sur mes moments de site plus tard, il fonctionne très bien. Ce qui se passe depuis le site en direct est allé et je l'ai pas eu de chance traquer la cause.

Ruby est une version 1.8.6 et rails est la version 1.2.6.

Quelqu'un d'autre a ce problème?

Ceci est l'erreur et stacktrace.

Un SystemExit a eu lieu la sortie /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.6/lib/fcgi_handler.rb:116:in » /usr/local/lib/ruby/gems/1.8/gems/ rails-1.2.6 / lib / fcgi_handler.rb: 116: dans exit_now_handler » /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.4/lib/active_support/inflector.rb:250:in to_proc '/usr/local/lib/ruby/1.8/net/protocol.rb:133:in appeler' /usr/local/lib/ruby/1.8/net/protocol.rb:133:in sysread »/ usr / local / lib / ruby ​​/ 1.8 / net / protocol.rb: 133: dans rbuf_fill '/usr/local/lib/ruby/1.8/timeout.rb:56:in timeout' /usr/local/lib/ruby/1.8/timeout. rb: 76: dans le délai d'attente '/usr/local/lib/ruby/1.8/net/protocol.rb:132:in rbuf_fill' /usr/local/lib/ruby/1.8/net/protocol.rb:116:in readuntil '/usr/local/lib/ruby/1.8/net/protocol.rb:126:in readline' /usr/local/lib/ruby/1.8/net/http.rb:2017:in read_status_line »/ usr / local / lib / ruby ​​/ 1.8 / net / http.rb: 2006: dans read_new '/usr/local/lib/ruby/1.8/net/http.rb:1047:in demande' /usr/local/lib/ruby/1.8/ net / http.rb: 945: en request_get » /usr/local/lib/ruby/1.8/net/http.rb:380:i n GET_RESPONSE '/usr/local/lib/ruby/1.8/net/http.rb:543:in start' /usr/local/lib/ruby/1.8/net/http.rb:379:in GET_RESPONSE »

Créé 02/08/2008 à 18:26
source utilisateur
Dans d'autres langues...                            


4 réponses

voix
8

Il faisait longtemps que je FCGI mais je pense qu'un processus de FCGI pourrait jeter un SystemExit si le fil est trop long. Cela pourrait être le service Web ne répond pas ou même une requête DNS lente. Certains résultats montrent une erreur Google similaire avec Python et FCGI afin de passer à bâtards serait une bonne idée. Ce poste est ma référence , je l' habitude de bâtarde d'installation et je me réfère toujours revenir.

Créé 03/08/2008 à 06:22
source utilisateur

voix
8

L'utilisation fcgi avec Ruby est connu pour être très buggy.

Pratiquement tout le monde a déménagé à Mongrel pour cette raison, et je vous recommande de faire la même chose.

Créé 02/08/2008 à 18:50
source utilisateur

voix
5

Je l'habitude d'obtenir ces tout le temps sur Apache 1. / FastCGI. Je pense que ça a causé par fastcgi suspendus avant Ruby est fait.

Le passage à bâtarde est une bonne première étape, mais il y a plus à faire. C'est une mauvaise idée de services de réforme des pages Web sur en direct, en particulier de Rails. Rails n'est pas thread-safe. Le nombre de connexions simultanées, vous pouvez soutenir est égal au nombre de roquets (ou processus de passagers) dans votre cluster.

Si vous avez un roquet et quelqu'un accède à une page qui appelle un service Web qui prend 10 secondes pour le temps, chaque demande à votre site Web expire au cours de cette période. La plupart des équilibreurs de charge juste faire défiler vos roquets aveuglément, donc si vous avez deux bâtards, tous les autres demande le délai expire.

Tout ce qui peut être lent imprévisiblement doit se produire dans une file d' attente d'emploi. Le premier coup à / lent / action ajoute le travail à la file d' attente, et / lent / l' action continue à rafraîchir par page est actualisée ou des requêtes via ajax jusqu'à ce que le travail est terminé, et vous obtenez vos résultats de la file d' attente d'emploi. Il y a quelques files d' attente d'emploi pour Rails de nos jours, mais le plus ancien et probablement le plus largement utilisé est un BackgroundRB .

Une autre alternative, selon la nature de votre application, est d'abattre le service toutes les N minutes via Cron, mettre en cache les données localement, et ont votre page en lecture à partir du cache.

Créé 30/08/2008 à 05:55
source utilisateur

voix
1

Je prendrais aussi un coup d' œil à passagers . Il est beaucoup plus facile d'y aller que la solution traditionnelle d'Apache / nginx + Mongrel.

Créé 11/08/2008 à 17:36
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more