Gurkentests schlagen bei 'Stream geschlossen (IOError)' fehl

9

Wir aktualisieren derzeit unsere Rails-App auf Rails 4. In Version 3.2 laufen unsere Cucumber (1.3.17) -Tests mit Capybara (2.4.4), Poltergeist (1.5.1) und PhantomJS gut (wenn auch langsam) (1.9.8) unter der Haube.

Aber in 4.0.12 und 4.1.8 erhalten wir stream closed (IOError) an einem zufälligen Punkt im Lauf:

%Vor%

Dieser Fehler ist nicht gleich wie ein closed stream -Fehler , was bedeutet, dass Sie versuchen, einen Stream zu berühren, nachdem dieser geschlossen wurde.

Nein, das einzige Mal, dass ein stream closed (IOError) in der gesamten MRT geworfen wird, ist in rb_thread_fd_close . Dieser Code wiederum wird nur in rb_io_close aufgerufen - aka beim Schließen eines Dateideskriptors ; Es iteriert durch die anderen Live-Threads und sieht, ob einer von ihnen auf den geschlossenen Dateideskriptor wartet. Wenn jemand wartet, wird der Fehler stream closed im wartenden Thread ausgelöst. Das erklärt genau, warum der Stack-Trace auf Gurke zeigt: Das ist der Thread, der darauf wartet, vom Formatierer auf STDOUT zu schreiben. Aber wir haben keine Informationen darüber, wer den Dateideskriptor geschlossen hat.

Da ich weiß, dass ich hier mit Threads zu tun habe, beginne ich suspect timeout tötet etwas, wenn es nicht sein sollte, aber ich kann nicht wissen, was timeout das Chaos verursacht; Ich habe das in meinem Code entfernt, aber dann 35 in verschiedenen Edelsteinen gefunden, die wir verwenden, und das Problem tritt immer noch auf.

Wir vermuteten auch irgendwann, dass einer der phantomjs-Prozesse wegen zu wenig Arbeitsspeicher gelöscht wurde, und wir fügten Instrumentierung zu puts dem Speicher des aktuellen Prozesses vor jedem Szenario hinzu ... und die IOError s verschwanden , fast sicher wegen Zeitproblemen. Als ich die Instrumentierung entfernte, kehrten die Fehler zurück.

Ich habe auch versucht, auf Gurken und Capybara zu aktualisieren, aber keiner schien einen Unterschied zu machen.

Gibt es eine clevere Möglichkeit, das nachzuverfolgen, was ich noch nicht versucht habe? Haben Sie dieses Problem erkannt und kennen Sie die Konfigurationsänderung in einer Zeile, die ich verbessern muss? Haben Sie einen praktischen Patch, der timeout von allen Ruby überall entfernt?

    
TALlama 04.12.2014, 23:36
quelle

2 Antworten

1

Ideen zu versuchen ...

  • Grenzen Sie das Problem ein, indem Sie Capybara + WebKit ausprobieren. Poltergeist ist nicht threadsicher (AFAIK).

  • Grenzen Sie das Problem ein, indem Sie sehen, ob es sich um ein Rack-Timeout handelt:

    %Vor%
  • Deaktivieren Sie vorübergehend alle Tests, die externe Geräte aufrufen, z. B. System, sidekiq, eventmachine, verzögerter Job usw.

  • Für Ihre Idee eines Patches, der Timeout von allen Ruby überall entfernt:

    %Vor%

    Siehe Schutz vor Timeout-Fehlern

  • Verfolgen Sie die geöffneten Dateiobjekte an beliebigen Haltepunkten:

    %Vor%

    Siehe Wo hält Ruby seine Offenheit fest? Dateideskriptoren

joelparkerhenderson 09.12.2014 22:22
quelle
0

probiere das aus:

Nachdem Sie die Datei zum Lesen geöffnet haben, müssen Sie sie schließen.    Siehe dieses ähnliche Problem

    
Sachin Singh 16.12.2014 05:07
quelle