4

My Rails-Anwendung verwendet das inherited_resources Gem. Ich versuche derzeit, es zu beschleunigen, um mit einem viel größeren Datensatz umgehen zu können. Also ging ich (mit Hilfe des Bullet Gem) nach vorne, um eifrig zu laden, wo es sich als hilfreich erweisen würde. Innerhalb inherited_resources sieht es so etwas wie dieses:Wie kann ich diesen Fehler beheben, während ich das Eager-Laden erhöht? "ERROR ThreadError: Versuch, einen Mutex zu entsperren, der von einem anderen Thread gesperrt ist"

def collection 
    my_widgets ||= end_of_association_chain.includes(:association_one, :association_two, :association_three, :association_four) 

    @widgets = case params[:filter] 
        when nil then my_widgets.all 
        when 'old' then my_widgets.old 
        when 'new' then my_widgets.new 
        end 

    @final_collection 
end 

Der neue Code ist .includes(:association_one, :association_two, :association_three, :association_four)

Diese einfache Änderung meine Ladezeit in den Protokollen riesige Datenbank von ca. 5 mal für meinen Test beschleunigt. Der Browser würde jedoch einfach da sitzen, leer. Nichts. Mit dem Chrom-Ladesymbol gehen.

Wenn ich den Server im Terminal töten, erhalte ich diese ziemlich einzigartig Fehler:

ERROR ThreadError: Attempt to unlock a mutex which is locked by another thread 

Backtrace am unteren Ende.

Ich habe bereits versucht, die Lösung in der Top-Antwort auf diese Frage diskutiert: How can I serve requests concurrently with Rails 4?, mit dem folgenden:

#config/environments/development.rb 
config.cache_classes = false 
config.eager_load = true 
config.allow_concurrency=true 

Was bin ich hier? Warum verleiht mir das Hinzufügen dieser Assoziationen zum Eager-Laden, das die Dinge hinter den Kulissen erheblich beschleunigt, mit diesem ThreadError einen nicht reagierenden Browser?

 
    /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/lock.rb:22:in `unlock' 
    /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/lock.rb:22:in `ensure in call' 
    /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/lock.rb:23:in `call' 
    /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/content_length.rb:15:in `call' 
    /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:88:in `service' 
    /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/httpserver.rb:138:in `service' 
    /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/httpserver.rb:94:in `run' 
    /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:294:in `block in start_thread' 
/Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:48:in `shutdown': undefined method `shutdown' for nil:NilClass (NoMethodError) 
    from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/server.rb:280:in `block in start' 
    from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:206:in `call' 
    from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:206:in `join' 
    from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:206:in `block (2 levels) in start' 
    from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:206:in `each' 
    from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:206:in `block in start' 
    from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:32:in `start' 
    from /Users/johndoeuser/.rvm/rubies/ruby-2.2.1/lib/ruby/2.2.0/webrick/server.rb:162:in `start' 
    from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/handler/webrick.rb:34:in `run' 
    from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/rack-1.6.4/lib/rack/server.rb:286:in `start' 
    from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/server.rb:80:in `start' 
    from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/commands_tasks.rb:80:in `block in server' 
    from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/commands_tasks.rb:75:in `tap' 
    from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/commands_tasks.rb:75:in `server' 
    from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands/commands_tasks.rb:39:in `run_command!' 
    from /Users/johndoeuser/.rvm/gems/ruby-2.2.1/gems/railties-4.2.6/lib/rails/commands.rb:17:in `' 
    from bin/rails:4:in `require' 
    from bin/rails:4:in `' 

edit: Ich fange an zu fragen, ob dies weniger einen Thread Fehler ist als meine Daten-Set zu groß für eifrigen Laden zu sein, gibt es eine Schwelle, wo Sie gerne Laden sind so viele Objekte, die, während sie schnell geladen im Terminal sitzt der Browser einfach für immer da?

Antwort

1

Ist der Wechsel von WEBrick zu Puma eine Option? Ich hatte eine Anwendung, die gleichzeitige Anfragen erforderte. Ich war immer der Fehler, den Sie beschrieben:

ERROR ThreadError: Attempt to unlock a mutex which is locked by another thread

zu Puma Schalt löste dieses Problem direkt aus der Box.

+0

Ich habe zu Unicorn gewechselt, um zu testen, es scheint * diesen Fehler zu stoppen, indem er für jetzt vorwarnte, aber er ist immer noch funktionsfähig über ungefähr 5.000 Objekte. Ich fange an mich zu fragen, ob es eine Lastgrenze gibt, die mein Browser von Active-Records-Objekten gleichzeitig verarbeiten kann. – Schwad

+0

Dies hat den Fehler behoben. Das größere Problem scheint zu sein, dass ich Daten nicht optimal behandelte und ActiveRecord etwas zu sehr missbrauchte. – Schwad