nicht angemeldet
implicit_flush PHP 5.5.7
Mahlzeit!
da ich nun letzte nach das erste mal meine eigene PHP-Version kompiliert habe (ich bitte um Applause, es hat genau einmal gefunzt, alle weiteren versuche sind kläglich gescheitert *g*) scheint es so, dass implict_flush nicht mehr zu funktionieren scheint ;(
laut phpinfo() ist implicit_flush=On, output_buffering=0, output_handler=nicht gesetzt
dennoch ist nun seit dem umstieg auf das neue PHP 5.5.7 (von 5.2.3) so, dass es scheinbar nicht mehr funktioniert ...
Hintergrund: ich aktualisiere gerade ein uraltes projekt, wo beispielsweise ladebalken simuliert werden, indem während des verarbeitens per JavaScript der ladebalken aktualisiert wurde bei vorgängen, die etwas länger dauern (bsp abrufen von mails von beliebig vielen mailkonten)
hat jemand eine Ahnung, woran das liegen könnte?
PHP läuft als FastCGI unter IIS 6.5 und IIS7, bei beiden das gleiche Problem ... ausgabepuffer und responsebufferlimits sind jeweils deaktiviert auf den Servern, die wurden ja im Prinzip nicht verändert, funktionierte ja vorher ;)
bin für jede Idee dankebar!
LG euer SorgenKind mech
-
Tach!
[...] scheint es so, dass implict_flush nicht mehr zu funktionieren scheint ;(
PHP läuft als FastCGI unter IIS 6.5 und IIS7, bei beiden das gleiche Problem ... ausgabepuffer und responsebufferlimits sind jeweils deaktiviert auf den Servern, die wurden ja im Prinzip nicht verändert, funktionierte ja vorher ;)Der Flush-Mechanismus war schon immer vom guten Willen des Webservers und der Konfiguration an sich abhängig. Besonders bei CGI, meine ich, geht das nicht. Ich weiß aber nicht, ob es irgendwo eine Übersicht über die Kombinationen gibt.
dedlfix.
-
Tach!
moinsen!
[...] scheint es so, dass implict_flush nicht mehr zu funktionieren scheint ;(
PHP läuft als FastCGI unter IIS 6.5 und IIS7, bei beiden das gleiche Problem ... ausgabepuffer und responsebufferlimits sind jeweils deaktiviert auf den Servern, die wurden ja im Prinzip nicht verändert, funktionierte ja vorher ;)Der Flush-Mechanismus war schon immer vom guten Willen des Webservers und der Konfiguration an sich abhängig. Besonders bei CGI, meine ich, geht das nicht. Ich weiß aber nicht, ob es irgendwo eine Übersicht über die Kombinationen gibt.
hm also wie gesagt die eigentliche serverkonfiguration hat sich nicht geändert, im Prinzip habe ich nur den php-ordner ausgetauscht, sprich der Server selbst hat einfach alle Einstellungen beibehalten.
PHP lief zuvor auch schon als fastCGI-Modul, daher weiß ich, dass es definitiv möglich ist. der entscheidende Faktor ist bei IIS das responsebufferlimit, welches auf 0 gesetzt werden muss, nur zur Info ;)
btw: welche alternativen würdet ihr mir vorschlagen, um den fortschritt eines Scripts zu visualisieren? (im Moment würde mir nur einfallen, den fortschritt mittels einer id in eine Tabelle zu schreiben und per Ajax sekündlich auslesen zu lassen ... was ich ziemlich umständlich finde)
-
moin nochmal,
also aktueler stand: ob_flush() bietet zumindest einen Workaround ...
ich habe jetzt ob_end_flush() genommen, da ich dieses nur einmal am anfang setzen brauch und somit die ausgabepufferung deaktiviert wird ... obwohl diese ja garnicht aktiviert sein sollte laut php.ini und auch nirgens ein ob_start vorhanden ist ... naja nur zur info ;)
LG euer Sorgenkind mech
-
Tach!
btw: welche alternativen würdet ihr mir vorschlagen, um den fortschritt eines Scripts zu visualisieren? (im Moment würde mir nur einfallen, den fortschritt mittels einer id in eine Tabelle zu schreiben und per Ajax sekündlich auslesen zu lassen ... was ich ziemlich umständlich finde)
Es gibt da mindestens 4 Möglichkeiten
- WebSockets
- Server Sent Events, aka EventSource (außer wohl Internet Explorer)
- Forever Frame
- Ajax long polling
Hab ich aus der FAQ zu SignalR geklaut. Das ist ein Modul für bidirektionale Kommunikation unter ASP.NET. Da gibt es sicher auch was fertiges für PHP als Backend.
dedlfix.
-
-