Wiederkehrende Schienen Fehler auf Heroku/Unicorn - 'Ausführung abgelaufen', ein ActionView :: Template :: Fehler

Meine Frage ist ähnlich wie folgt, aber geschieht unter etwas anderen Umständen.Wiederkehrende Schienen Fehler auf Heroku/Unicorn - 'Ausführung abgelaufen', ein ActionView :: Template :: Fehler

Rails: execution expired on time_zone_select

Mein Setup ist:

Rails 3.2.13
Unicorn 4.6.2
Mongoid 3.0.22
Mofa 1.4.2

Laufen auf Heroku Cedar. MongoDB wird auf MongoLab gehostet.

Die Fehler kommen in Chargen und werden oft durch einen Neustart des Heroku-Prozesses gelöst. Die erste ist normalerweise die folgende:

An ActionView::Template::Error occurred in [controller]#[action]: 

execution expired 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `read'

Das folgende ist das oberste Bit des Stack-Trace. Gerne bei Bedarf mehr hinzufügen!

vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `read' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `block in read' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:118:in `handle_socket_errors' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `read' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:177:in `read_data' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:99:in `block in read' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:202:in `with_connection' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:97:in `read' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/protocol/query.rb:163:in `receive_replies' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:135:in `block in receive_replies' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:134:in `map' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:134:in `receive_replies' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:553:in `block (2 levels) in flush' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:129:in `ensure_connected' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:551:in `block in flush' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:566:in `logging' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:550:in `flush' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:539:in `process' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:349:in `query' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cursor.rb:138:in `block in load_docs' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/session/context.rb:105:in `block in with_node' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cluster.rb:250:in `with_secondary' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/session/context.rb:104:in `with_node' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cursor.rb:137:in `load_docs' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cursor.rb:25:in `each' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/query.rb:76:in `each' 
vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/query.rb:76:in `each' 
vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual/mongo.rb:132:in `block in each' 
vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual/mongo.rb:556:in `selecting' 
vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual/mongo.rb:131:in `each' 
vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual.rb:18:in `each'

Rack-:: Timeout wird für 10 Sekunden (ich glaube, dass durch eine der Caching-Tutorials vorgeschlagen wurde ich gelesen) - wenn die Antwort den Timeout zu erhöhen, ist, das ist in Ordnung. Aber ich frage mich, ob dies nicht ein langsames Abfrageproblem ist? Das Verhalten scheint darauf hinzuweisen, dass es nur einer der Unicorn-Prozesse ist, die aufgelegt werden (weshalb ein Neustart von ps es zu heilen scheint).

Alle Gedanken oder Tipps würden sehr geschätzt werden!

Quelle

2013-05-24 nlh

ich das gleiche Problem/Stacktrace auf EC2 mit einem sehr ähnlichen Stapel zu sehen. – nont

Dies ist keine Lösung für das Problem, aber ein kleiner Workaround (und nicht unbedingt ein guter) - ich habe Unicorn für Puma ausgeschaltet und bis zu 2 Dynos auf Heroku gestoßen und das Problem wurde um einen GROSSEN Faktor reduziert. Aber es ist immer noch nicht gelöst und ich bekomme immer noch eine Handvoll 'Execution Expired' Fehler pro Tag (was weniger als eine Handvoll pro Stunde ist). Mein Bauchgefühl sagt, dass dies ein Mongoid/MongoLab-Problem ist - entweder eine langsame Abfrageantwort oder das Aufhängen offener Verbindungen mit einer nicht-lokalen Datenbank. – nlh

Update # 2: Es passiert immer noch viel, sogar mit 2 Dynos & Puma anstelle von Unicorn. Seufzer. – nlh

Ich würde vorschlagen, dass dies ein Problem mit Herokus Datei oder Netzwerksystem ist. Die angehängte Lese-Methode ruft 'Kernel :: select auf. Wählen Sie es selbst aus ist ein System-blockierender Aufruf, der darauf wartet, dass IO-Objekte lesbar werden. In diesem Fall ist es der TCP-Port, der die externe Verbindung zu MongoLab herstellt. Es könnte eine Reihe von Gründen geben, warum der TCP-Port nicht lesbar ist. Netzwerk- und Dateiprobleme kommen mir in den Sinn. Ich bezweifle, dass es eine lange Abfrage ist, da der Socket während der Ausführung der Abfrage dort für Select nicht blockiert würde die Ausführung des Skripts. Wenn das Problem weiterhin besteht, würde ich in Erwägung ziehen, von Heroku oder einer externen Datenbank in einem anderen Netzwerk wegzugehen. AWS ist immer eine gute Wahl, da sie eine sehr geringe Latenz zwischen Boxen (Boxen) haben.

HTH

Quelle

2013-08-22 06:10:29 Stewart

versuchen, die Ruby-Version auf 1.9.3 in Ihrem Gemfile Einstellung, dann bündeln, begehen und bereitstellen wieder

Quelle

2015-07-18 03:24:17 Maysam

Wiederkehrende Schienen Fehler auf Heroku/Unicorn - 'Ausführung abgelaufen', ein ActionView :: Template :: Fehler

Antwort

Verwandte Themen