2010-11-26 6 views
0

je veux programmer mon travailleur en utilisant une tâche cron pour vérifier la connexion de base de données périodiquement (par exemple comme 5 minutes) et mettre à jour une clé memcache en conséquence. donc dans mon application si je trouve la variable memcache à définir. Je rend mes pages différemment alors, lorsque la base de données est en place.workling ne marche pas le travail lorsque la base de données est dans mon application rails

Mais le problème est, le travailleur commence quand la base de données est en panne. quand la base de données est en place. il découvre correctement que la connexion à la base de données est présente et met à jour la variable memcache et tout fonctionne correctement.

Je ne sais pas, pourquoi le travailleur ne démarre pas lorsque la base de données est en panne. Je suis à court de délai. Toute aide sera grandement appréciée !

Mise à jour:

Ceci est l'erreur que je reçois lorsque le workling ne commence pas

/apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/ gems/1.8/gems/activerecord-2.1.1/lib/enregistrement_actif/connection_adapters/mysql_adapter.rb: 527: dans real_connect': Can't connect to MySQL server on '10.223.2.50' (111) (Mysql::Error) from /apps/Symantec/shasta/website/vendor/plugins/workling/script/../lib/workling/starling/poller.rb:35:in rejoindre ' depuis /apps/Symantec/shasta/website/vendor/plugins/workling/script/../ lib/workling/starling/poller.rb: 35: dans listen' from /apps/Symantec/shasta/website/vendor/plugins/workling/script/../lib/workling/starling/poller.rb:35:in chaque ' de /apps/Symantec/shasta/website/vendor/plugins/workling/script/../lib/workling/starling/poller.rb:35: dans listen' from /apps/Symantec/shasta/website/vendor/plugins/workling/script/listen.rb:19 from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/application.rb:203:in load ' à partir de /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/application.rb:203:in start_load' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/application.rb:296:in démarrer ' à partir de /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb: 51: dans watch' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:51:in fork ' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor .rb: 51: dans watch' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:45:in chaque ' à partir de /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/ daemons/monitor.rb: 45: dans watch' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:44:in boucle ' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0 /lib/daemons/monitor.rb:44:in watch' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:84:in start_with_pidfi le » de /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:64 : dans fork' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor.rb:64:in start_with_pidfile ' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/monitor. rb: 111: dans start' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/application_group.rb:149:in create_monitor ' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons /application.rb:283:in start' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/controller.rb:70:in exécutez ' à partir de /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/ lib/daemons.rb: 143: dans run' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons/cmdline.rb:112:in appelez ' à partir de /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0 /lib/daemons/cmdline.rb:112:in catch_exceptions' from /apps/Symantec/shasta/website/install/local/ruby-1.8.7-p299/lib/ruby/gems/1.8/gems/daemons-1.1.0/lib/daemons.rb:142:in exécutez ' à partir de script/workling_starling_client: 17

Répondre

1

Peut-être que le travailleur tente de se connecter à la base de données lors du démarrage (toujours) et déclenche une exception? Avez-vous des erreurs consignées par le travailleur?

Avez-vous écrit votre travail dans Rails? Peut-être écrire un script shell, qui supposera que la base de données est en panne lorsque le travailleur ne peut pas démarrer?

MISE À JOUR: Dans votre trace de la pile, il est le point de départ: script/workling_starling_client:17. Qu'y a-t-il, dans la ligne 17?

Comme la première ligne (le message d'exception lui-même) dit que " real_connect ': Impossible de se connecter au serveur MySQL sur '10 .223.2.50' (111) (Mysql :: Error)" alors il sera assez si vous encapsulez la ligne 17 (éventuellement avec quelques autres) dans un bloc "rescue", et vérifiez le message d'erreur s'il a la réponse que vous cherchez:

(Bien sûr, ne vous arrêtez pas ici. vos chèques, comme le manque d'exception ne pas signifie que la connexion est établie)

begin 
    line_17_is_here 
rescue => e 
    if e.message =~ /Can't connect to MySQL/ 
    handle_your_no_connection_state 
    else 
    raise e 
    end 
end 

La question est: pouvez-vous gérer l'état sans connexion sans ActiveRecord?

+0

J'ai joint l'exception lancée par le travailleur. – anusuya

+0

Ok, j'ai mis à jour la réponse. – Arsen7

+0

Je songe à laisser tomber workling complètement pour cela. mais exécutez plutôt un scintillement ruby ​​en arrière-plan dans scripts/check.rb qui met à jour la variable memcache que mon site web vérifie pour voir si db est connecté ou non. mais dans mon script ruby, si j'utilise require 'memcache'. il lance un et loadError .cant trouve memcache. – anusuya

Questions connexes