[RAILS] Über das Problem des Deadlocks bei der Parallelverarbeitung in gem'sprockets '4.0

Über Edelsteinprockets

Eine Bibliothek, die Süßigkeiten-Dateien kompiliert. Ab Rails 5.1 wird jedoch "Webpacker" für den Javascript-Compiler empfohlen, und ab Rails 6.0 wurde die Standardeinstellung für den Javascript-Compiler in "Webpacker" geändert. Wird derzeit als Standard für die CSS- und Bildkompilierung verwendet.

CSS, image -> sprockets javascript -> webpacker

Phänomen

Das Ausführungsergebnis wird nicht durch Asset-Vorkompilierung zurückgegeben.

Lösungen

1. Nehmen Sie Einstellungen vor, um die Parallelverarbeitung zu deaktivieren.

Wenn Sie in den Anwendungseinstellungen eine der folgenden Einstellungen vornehmen, wird die Parallelverarbeitung deaktiviert und es treten Probleme auf.

Rails.config.assets.export_concurrent = false
Sprockets.export_concurrent = false

2. Verwenden Sie Version 3 der Kettenräder

Die Wartung der Edelsteinprockets ist langsam, und es wird erwartet, dass die Reparatur einige Zeit in Anspruch nimmt. Daher sollten 3 Serien verwendet werden.

Einzelheiten

Sprockets 4.0 wird jetzt mit mehreren Threads und parallel ausgeführt, um die Kompilierungsleistung zu verbessern. See: https://github.com/rails/sprockets/pull/469

Die gleichzeitige Verarbeitung verwendet "Concurrent :: Promise" und dann "wait!" In "versprechen.each (&: wait!)".

promises = args.flatten.map do |path|
  Concurrent::Promise.execute(executor: executor) do
    environment.find_all_linked_assets(path) do |asset|
      yield asset
    end
  end
end
promises.each(&:wait!)

See: https://github.com/rails/sprockets/pull/469/files#diff-0d972076f2fbe7a73281fcc0282e57a1618bba231bc8023a4d5bc5705fb06da7R123-R130

Zu diesem Zeitpunkt wartet die Methode "wait!" Auf die Zeitüberschreitung, bis die Verarbeitung abgeschlossen ist. Da jedoch kein Argument angegeben ist, wird "nil" eingegeben und wartet für immer.

def wait!(timeout = nil)
  wait(timeout).tap { raise self if rejected? }
end

See: https://github.com/ruby-concurrency/concurrent-ruby/blob/ffed3c3c0518030b0ed245637703089fa1f0eeee/lib/concurrent/concern/obligation.rb#L79-L89

Wenn während der Parallelität ein Deadlock auftritt, wird der Vorkompilierungsprozess für Assets niemals beendet. Es scheint, dass mehrere Threads blockieren und versuchen, dieselbe Datei während der parallelen Verarbeitung zu kompilieren. Ruby-Concurrency-Fehler? Es besteht die Möglichkeit von. https://github.com/ruby-concurrency/concurrent-ruby/issues/870

Es gibt auch viele ähnliche Probleme. See: https://github.com/rails/sprockets/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+thread+OR+concurrent

Referenz

https://github.com/rails/sprockets/issues/640 https://github.com/rails/sprockets/issues/581 https://github.com/ruby-concurrency/concurrent-ruby/issues/870 https://github.com/ruby-concurrency/concurrent-ruby/blob/ffed3c3c0518030b0ed245637703089fa1f0eeee/lib/concurrent/synchronization/lockable_object.rb#L6-L20

Andere

Diskussionen über Kettenräder finden Sie auch auf der WTF-Seite unten. https://discuss.rubyonrails.org/t/sprockets-abandonment/74371/24