2014-04-29 3 views
9

Bei der Entwicklung einer bestimmten Website habe ich ein zeitweiliges Problem beim Laden der Website in Firefox (konnte nicht in IE oder Chrome vergleichen). Die Website lädt mehrere Javascript-Dateien, CSS-Stylesheets, Bilder usw. Gelegentlich können eine oder mehrere der Dateien nicht ordnungsgemäß geladen werden. Die Antwort zeigt einen Status von 200 OK an, aber die Inhaltslänge gibt 0 an. Dies geschieht auf verschiedenen Dateien zu unterschiedlichen Zeiten. Wenn es sich um eine JavaScript-Datei handelt, die nicht geladen werden kann, funktioniert die Website nicht ordnungsgemäß, aber möglicherweise weiterhin Inhalt. Wenn es passiert, die Datei index.html sein, die nicht geladen werden kann, zeigt Firefox eine leere Seite mit dem folgenden html:HTTP-Anfrage gibt 200 OK, aber keinen Inhalt als Antwort

<html> 
<head></head> 
<body><pre></pre></body> 
</html> 

(Ich glaube, das als Standard von Firefox kommt „leer“ Seitenaufruf)

Es scheint, dass vorherige erfolgreiche Ladevorgänge ordnungsgemäß aus dem Browser-Cache abgerufen werden können und der Antwortstatus 304 nicht geändert lautet. Nach einem Fehler sehen wir das nächste Mal, wenn die Ressource angefordert wird, einen Antwortstatus von 200 OK, wobei nachfolgende Anforderungen erneut mit 304 antworten.

Hier sind Beispiele für die Request/Response-Header, wie Firebug berichtet:


Allgemeine Erfolgsfall: (Antwort Status: 304 nicht geändert, Content-length: 288)

Request-Header:

Accept: */* 
Accept-Encoding: gzip, deflate 
Accept-Language: en-US,en/q=0.5 
Connection: keep-alive 
Cookie: JSESSIONID=<shouldn't matter> 
Host: ???.???.???.???:8442 
If-Modified-Since: Tue, 29 Apr 2014 13:18:26 GMT 
If-None-Match: W/"228-1398777506000" 
Referrer: https://???.???.???.???:8442/mySite/ 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0 

Antwort Sockel:

Cache-Control: no-cache 
Date: Tue, 29 Apr 2014 13:36:35 GMT 
Etag: W/"288-1398777506000" 
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00 
Pragma: No-cache 
Server: Apache-Coyote/1.1 

Antwort Header von Cache:

Accept-Ranges: bytes 
Cache-Control: no-cache 
Content-Length: 288 
Content-Type: text/javascript 
Date: Tue, 29 Apr 2014 13:36:35 GMT 
Etag: W/"288-1398777506000" 
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00 
Last-Modified: Tue, 29 Apr 2014 13:18:26 GMT 
Pragma: No-cache 
Server: Apache-Coyote/1.1 

Die Registerkarte Cache in Firebug zeigt Folgendes an:

Data Size: 288 
Device: disk 
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST) 
Fetch Count: 81 
Last Fetched: Tue Apr 29 2014 08:28:35 GMT-05:00 (CDT) 
Last Modified: Tue Apr 29 2014 08:28:35 GMT-05:00 (CDT) 

Fehlgeschlagen Fall: (Antwort Status: 200 OK, Content-length: 0)

Anforderungsheader:

Accept: */* 
Accept-Encoding: gzip, deflate 
Accept-Language: en-US,en/q=0.5 
Connection: keep-alive 
Cookie: JSESSIONID=<same as above> 
Host: ???.???.???.???:8442 
If-Modified-Since: Tue, 29 Apr 2014 13:18:26 GMT 
If-None-Match: W/"228-1398777506000" 
Referrer: https://???.???.???.???:8442/mySite/ 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0 

Antwort-Header:

Content-Length: 0 
Date: Tue, 29 Apr 2014 13:36:28 GMT 
Server: Apache-Coyote/1.1 

Die Registerkarte Cache in Firebug zeigt Folgendes an:

Data Size: 
Device: disk 
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST) 
Fetch Count: 83 
Last Fetched: Tue Apr 29 2014 08:28:42 GMT-05:00 (CDT) 
Last Modified: Tue Apr 29 2014 08:28:42 GMT-05:00 (CDT) 

Weiter Erfolgsfall: (Antwort Status: 200 OK, Content-length: 288)

Anforderungsheader:

Accept: */* 
Accept-Encoding: gzip, deflate 
Accept-Language: en-US,en/q=0.5 
Connection: keep-alive 
Cookie: JSESSIONID=<same as above> 
Host: ???.???.???.???:8442 
Referrer: https://???.???.???.???:8442/mySite/ 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0 

Antwort-Header:

Accept-Ranges: bytes 
Cache-Control: no-cache 
Content-Length: 288 
Content-Type: text/javascript 
Date: Tue, 29 Apr 2014 13:37:03 GMT 
Etag: W/"288-1398777506000" 
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00 
Last-Modified: Tue, 29 Apr 2014 13:18:26 GMT 
Pragma: No-cache 
Server: Apache-Coyote/1.1 

Die Registerkarte Cache in Firebug zeigt Folgendes an:

Data Size: 288 
Device: disk 
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST) 
Fetch Count: 85 
Last Fetched: Tue Apr 29 2014 08:28:54 GMT-05:00 (CDT) 
Last Modified: Tue Apr 29 2014 08:28:53 GMT-05:00 (CDT) 

wir die Seite in JBoss-EAP v6.1 hosten, und ich habe schon versucht, diese in Firefox 10, 17 und 24 mit den gleichen Ergebnissen. Ich verstehe, dass es neuere Versionen gibt (nicht zu erwähnen verschiedene Browser), aber sie sind nicht unbedingt eine Option für uns. Ich hoffe, dass die Lösung eine einfache Konfigurationsänderung ist, aber bei meinen Versuchen, nach diesem Problem zu suchen, habe ich niemanden gesehen, der das gleiche Problem hat, also ist es vielleicht nicht so einfach. Ich freue mich über Vorschläge. Bitte lassen Sie mich auch wissen, wenn ich weitere Informationen bereitstellen muss (z. B. web.xml, jboss.conf, etc

)

Weitere Produkte in der Mischung:

  • Require.js v2.1.2
  • Java 1.6
  • CAS 3.2.1
  • Atmosphäre 2.1.3

Update: Ich habe die Möglichkeit eines Cache-Problems im Wesentlichen ausgeschlossen. Ich implementiert einen Cache-Busting-Modul Ladeprozess wie in der RequireJS API Seite vorgeschlagen, und ich immer noch das Problem sehen. Diesmal sind sie jedoch statt aller 304 Statuscodes alle 200er.


Update 2: ich die Quelle für jbossweb 7.2.0.Final heruntergeladen und bearbeitet dieses Problem durch das Debuggen. Offenbar gibt es eine Klasse org.apache.coyote.http11.Http11ConnectionHandler genannt, die einen Pool von Http11Processor Instanzen unterhalten, jede mit ihren eigenen Request und Response-Objekten. Wenn eine Anfrage abgeschlossen ist, wird der Http11Processor "recycled" und in den Pool zurückgelegt.

Es scheint, dass in der Wiederverwendungslogik ein Threading-Problem auftreten kann, da Response.recycle das "committed" auf false setzen soll, aber mein (bedingter) Haltepunkt unmittelbar nach dem Aufruf von response.recycle() stoppt mit antwort.committed == wahr. Dies verursacht später die fehlgeschlagenen Antworten. Wenn ein Http11Processor ein bereits festgeschriebenes Response-Objekt enthält, kann die Response nicht zum Zurückgeben von Informationen verwendet werden. Es reagiert einfach mit Status: 200, Content-Length: 0

Dies scheint der Fall zu sein, wenn ich eine Webseite zu schließen, die eine Atmosphäre Verbindung hat, die Server-Side-Events verwendet. Benutzt ich die Atmosphere-Verbindung nicht richtig? Gibt es eine spezielle Bereinigungslogik, die ich implementieren sollte?

Antwort

5

Nach vielen Untersuchungen und Debugging, fand ich, dass die Atmosphäre Bibliothek aus einem Response-Objekt zu manipulieren erlaubt wurde, die recycelt worden war und für eine spätere Anfrage Gewöhnung. Die betroffene Response erhielt den Status 200, content-length von 0 und wurde so festgelegt, dass keine weiteren Änderungen vorgenommen werden konnten. Der unglückliche Anforderungs-Thread, der diese "beschädigte" Antwort-Instanz erhält, kann nicht zum Bereitstellen des tatsächlichen Inhalts verwendet werden.

Um diese Änderung von Auswirkungen auf den JBoss-Server zu verhindern, habe ich folgendes in die jboss.properties Datei:

org.apache.catalina.connector.RECYCLE_FACADES=true 

Eine weitere Option ist ein Security Manager zu verwenden. (Siehe Abschnitt Sicherheit this Seite und den Rat in den letzten paar Absätze von this Seite angeboten)

Dies verhindert, dass offenbar das Recycling von Anfragen und Antworten, so dass wir immer eine frische Antwort Instanz für jede Anfrage erhalten.

+0

Hallo, ich benutze jboss eap 6.4, primefaces 5.3 und Atmosphäre 2.4.8. Ich habe genau das selbe Problem wie du, aber nachdem ich die org.apache.catalina.connector.RECYCLE_FACADES Eigenschaft zu standalone.xml hinzugefügt habe, bin ich auf eine Ausnahme gestoßen (Interceptor Atmosphere LifeCycle abgestürzt. Die Verarbeitung wird mit einem anderen Interceptor fortgesetzt: java.lang .IllegalStateException: JBWEB000057: Das Anforderungsobjekt wurde wiederverwendet und ist nicht mehr mit dieser Fassade verknüpft). Haben Sie ein ähnliches Problem festgestellt? – bluebloodedboy

+0

Ich habe diese Ausnahme gesehen. Ich habe eine Menge anderer Arbeiten um Atmosphere getan, die AtmosphereResource-Instanzen aufräumen, hauptsächlich aufgrund der Tatsache, dass ich den BlockingIOCometSupport verwende (nur wegen eines Mangels an AsyncIO-Unterstützung). In unserer Anwendung gibt es genügend Durchläufe durch AtmosphereResources, dass diese Ausnahme keine drastischen Probleme verursacht hat (die wir bisher bemerkt haben). – pacifier21

0

Sie haben wahrscheinlich einen Versuch catch-Block, der den Fehler beim Schlucken und keine Ausgabe zu erzeugen. Es könnte den Fehler irgendwo protokollieren.

+0

dass auf jeden Fall eine vernünftige Theorie. Ich habe nach irgendwelchen Ausnahmen gesucht, konnte aber nichts finden.In meinem Debugging (mit Eclipse) habe ich einen "Stop auf gefangen/nicht abgefangene Exceptions" hinzugefügt und nichts Ungewöhnliches gefunden. Ich werde das im Hinterkopf behalten, aber ich glaube nicht, dass das die Ursache ist. Siehe Update 2 in der Frage. – pacifier21