EWS Update :
Contrairement à ce que j'avais indiqué précédemment, EWS 2.9.0 n'utilisera pas MySQL 5.5. En effet cette version de MySQL est incompatible avec Windows 2000. De plus la taille des exécutables de cette version a encore augmenté de façon significative... Et ils contiennent beaucoup de "vide" censé aider au débogage de mysql... allez comprendre...

EWS v2.9.0 (7 Nov 2010) :
[geshifilter-code]
+ Updated Apache to 2.2.17
* Apache: removed iso default charset setting (to support utf8 static .html files)
+ HTTPS configuration (self signed crt), just enable mod_ssl in httpd.conf
* Updated style of directory indexes
+ Updated MySQL to 5.1.52
+ Updated PHPMyAdmin to 3.3.8
+ Added XDebug dev version 2.2.0-dev (r3369), 2.1.0 version also available
+ Changed eAccelerator module version format, see rev. in dll file properties
+ Added jQuery UI 1.8.6 (contains jQuery 1.4.3) and 2 php bridges (future use)
+ EWS enhancements
+ Language selection
* New EWS Icon
* Fixed my.ini path for EWS manager MySQL config button
* Updated admin page theme
+ Ready for future MySQL 5.5.6 (RC)[/geshifilter-code]
This version has been checked on Windows 2000 and Windows Seven.
Apache seem's now ok on shutdown, contrary to the 2.8.0 EWS version (on Windows 2000).
Why PHP 5.2.13 ?
The 5.2.14 PHP version has a problem on Windows with php_curl.dll extension. PHP loading time is huge in command line (and so CGI mode too). This could be related to zlib.dll and SSL librairies (libeay32.dll), but i dont have any solution for the moment. The 5.3.3 version has also this problem and that is not related to extension source code, which wasnt modified recently.
EDIT (Dec 2010) : The problem is related to the RAND_screen() function in libeay32.dll used to init random values from user input (thing which must not be used in a server and PHP) It's really specific to Windows. This bugs still appears in 5.3.4 VC6 TS (3 seconds) . It was less than one second in 5.3.2 and 5.2.13.
Commentaires
Jaimerais savoir si votre
Jaimerais savoir si votre wdscript est capable de gerer les threads et les variables globales , car si jai bien saisi apache cree un thread wdscript a chaque appel dun usagers differents.
ce qui pause le problème suivant le partage de valeur des variables globales entre threads et
l'utilisation du même fichier en même temps
donc est-il prévu dans le code wdscript la gestion de ces problèmes
ou
doit - on nous même faire la gestions avec sémaphores et mutex
car si j'ai dans l'idee que votre application est prévue comme extracteur de base personnel ?
avez-vous déjà eu rapport de quel que problème en ce qui concerne son utilisation d'une facon professionnelle ?
peut-on l'utiliser en production ?
en mode CGI, ce sont des
en mode CGI, ce sont des programmes différents donc pas de partage de variable globale.
en mode FastCGI c'est un peu différent :
apache utilise plusieurs processus de wdscript pour travailler, mais 1 processus wdscript n'execute pas de traitement parallèle... donc pas de sémaphore ou mutex à gérer... apache utilise le premier wdscript disponible...
a chaque requete, une instance de classe WDScript est créée, avec ses propres "variables", il n'y a pas de variables globales à utiliser, les pages sont l'équivalent de fonctions.
Oui, wdscript est utilisé en production, mais pas forcement avec EWS...
Poster un nouveau commentaire