Versions antérieures

• Corrections
  1. un bug corrigé dans le script xwtar.sh qui génère l’archive des fichiers sources (cette archive est maintenant correctement générée).

• Corrections
  1. cette version insère les scripts de vérification et de configuration de la base de données qui étaient manquant dans la version 6.0.0

• Corrections
  1. un bug corrigé au niveau du téléchargement des données : si un fichier n’est pas disponible au niveau du serveur, la partie distribuée (worker, client) en est correctement informée
  2. un bug corrigé dans la gestion du signal “alive” du côté du serveur
  3. un bug corrigé dans les paquets d’installation
  4. xwversion retourne 1 si le client devrait être mis à jour
  5. un bug corrigé dans la gestion des données (WIN32 worker)
  6. xwconfigure introduit les paramètres –newkeystore et–newalias. Par
     défaut les keystores sont crées s’ils n’existe pas et restent inhangés sinon.
     • –newkeystore peeut être utilisé pour forcer la regénération du keystore. Ceci annule tout déploiement éventuel.
     • –newalias peut être utilisé pour créer un nouvel alias dans le keystore existant.
       Ceci permet d’utiliser un déploiement au delà de la date d’expiration du keystore en cours.
• Nouvelles fonctionnalités
  1. paquets RPM et Debian pour le client
  2. nouvelles colonnes dans la table “Host”
     • -osversion
     • -javaversion
     • -javadatamodel
  3. la définition des applications permet désormais de gérer les binaires Windows X86_64
  4. Java 6 SystemTray

• Corrections
  1. un bog corrige dans les requêtes SQL

• Corrections
  1. mise à niveau des installeurs Mac OS X : ils sont maintenant compatible toutes versions (y compris 10.6)
  2. le (un)marshalling XML amélioré : gain des performances jusqu’à 20% (voir ci après)
  3. Les scripts xwhepgenserverkey, xwhepgenworkerkey, xwhepgenclientkey sont remplacés par le seul script xwhepgenkeys qui est automatiquement généré par xwconfigure
• Nouvelles fonctionnalités

  la plate-forme est maintenant capable de mettre automatiquement à jour la clé publique du serveur. Cette fonctionnalité doit être mise en oeuvre avant que la clé actuelle n’expire.

  • Sujet : utiliser un déploiement au delà de la validité de la clé initiale du serveur.
  • Quoi: distribuer automatiquement la clé publique du serveur aux workers et (sur demande) aux clients.
  • Quand: avant que la clé actuelle du serveur n’expire
  • Comment :
    1. créer une nouvelle clé pour le serveur avec le script xwhepgenkeys
    2. insérer le keystore du worker ainsi mis à jour (containant donc les clés publiques du serveur actuelles et nouvelles) en tant que donnée publique
    3. arrêter le serveur
    4. positionner la variable keystore.uri dans le fichier xtremweb.server.conf
    5. redémarrer le serveur
  • Securité : La sécurité est toujours assurée :
    • les workers et les clients doivent posséder la clé actuelle du serveur pour pouvoir télécharger le nouveau keystore
    • le téléchargement est crypté
    • les workers et les clients doivent présenter une identité valide pour ce téléchargement
    • le keytore distribué ne contient que des clés publiques

XML un/marshalling has been improved. This results to an 20% performances increase as shown in the two next figures which represent the client execution time to retreive 1000 jobs from server of our XWHEP deployment at LAL. In the first figure we can see that the client needed more than 100 seconds using XWHEP 5.8.0; in the second figures less than 80 seconds is now needed using XWHEP 5.9.0.

• Corrections
  1. un bug corrigé les scripts d’initialisation

• Corrections
  1. le script xwhep.bridge.pl a été corrigé pour être compatible avec les versions 5.8.x

• Corrections
  1. le script xtremweb.tests.pl a été corrigé
  2. worker : un bug corrige dans l’envoi des résultats
  3. serveur : l’ordonnanceur peut être défini dans le fichier de config et chargé au lancement
  4. l’ordonnanceur a été totalement réécrit: il était buggé, conceptuellement erroné et ne gère pas les tâches équitablement entre les utilisateurs. Dans cette version, l’ordonnanceur :
     • n’utilise plus de cache DB pour éviter des fuites de mémoires
     • améliore l’utilisation des requêtes SQL
     • a l’entière responsabilité de la gesion des tâches:
       • retreive() passe les tâches de WAITING a PENDING
       • select() gère les tâches PENDING sur requête des workers
     • toutefois cette version ne gère toujours pas les tâches équitablement entre les utilisateurs (on est toujours en 1er arrivé 1er servi 🙁 )
  5. les logins des utilisateurs peuvent être réutiliser (le login d’un utilisateur effacé peut être réutilisé pour un nouvel utilisateur)
  6. les noms des groupes d’utilisateurs peuvent être réutiliser (le nom d’un groupe effacé peut être réutilisé pour un nouveau groupe)
  7. les mots de passe ne transitent plus
  8. les processeurs X86_64 sont correctement pris en charge pour les machines Apple
  9. des fuites de mémoires ont été corrigées au niveau du serveur. Les graphes ci dessous montrent l’utilisation de la mémoire par le serveur. Le 1er montre une utilisation trop importante avec la version 5.7.7 : il utilise jusqu’à 600Mb. Le 2nd montre une utilisation beaucoup plus raisonnable et surtout très stable avec la version 5.8.0 : le server se contente de 288Mb.

     
     

• Nouvelles fonctionnalités.

  Certaines nouvelles fonctionnalités sont introduites afin d’améliorer le confinement et la sécurité.

  • les droits utilisateurs ont été légèrement modifiés: ADVANCED_USER permet de gérer des groupes utilisateurs. Conséquences : pour chaque groupe, il faut définir un administrateur pour gérer ce groupe (users, applications)
  • tout objet peut maintenant être confiné: ils ont tous les champs OWNERUID et ACCESSRIGHTS (AR).
  • xwchmod s’applique donc à tout objet

  Conséquences :

  • les identités administrator et worker sont privées (AR : 0x700) et n’apparaissent donc pas avec la commande xwusers
  • on peut confiner les groupes utilisateurs (AR: 0x750)
  • les utilisateurs d’un groupe hérite leurs AR de leur group
  • les utilisateurs doivent être insérés par l’administrateur du groupe (cad que leur OWNER doit être l’admin du groupe)
  • les utilisateurs d’un group confinés ne sont listés que pour les membres du groupe
  • on insère désormais un group en fournissant l’admin comme ceci:
    $> xwsendusergroup MyGroupLabel theGroupAdminLogin theGroupAdminPassword theGroupAdminEmail
    
    Un groupe non confiné fonctionne comme dans les versiosn précédentes.

  • Cette version introduit un système de versionning. Tous les messages (requêtes, réponses) sont maintenant encapsulés dans un élément racine ...
    De telle manière que la version soit maintenant incluse dans le protocole.
    Des champs ont été modifiés/renommés/ajoutés/retirés dans cette version : les objects ont tous les champs OWNERUID and ACCESSRIGHTS. Certains avec un champ CLIENTUID or USERUID qui ont été renomés OWNERUID.

    Bien sûr, les versions précédentes ne peuvent pas connaitre ces changements. A partir de cette versions 5.8.0 le protocole sait tenir compte de la version des clients/workers. S’ils envoient un message sans l’element XML xwhep c’est qu’ils tournent une version plus ancienne que la 5.8.0 et le serveur retrourne alors un réponse compatible.

• Corrections
  1. workpoolsize est forcé à 1 suite à des problèmes de concurrence d’accès avec une valeur supérieure
  2. un bug corrigé dans Executor streams
  3. un bug corrigé dans la gestion des tâches perdues
• Nouvelle fonctionnalité
  • -AUCUNE-

• Corrections
  1. communications TCP : un bug résolue au niveau de la reconnection suite à une erreur réseau
  2. XWHEP 5.7.5 a introduit la notion de limite dans le nombre d’entrées du niveau du cache (à 10K entrées), mais l’implémentation était buggée : elle a été corrigée. Le cache gère désormais ses entrées en utilisant le mode LRU (least recently used)
  3. serveur : la détection des tâches perdues se faisaient toutes les 15s, ce qui n’est absolument pas nécessaire; cette nouvelle version effectue la vérification toutes les ALIVETIMEOUT minutes (default : 5mn).
  4. un bug corrigé dans l’access logger : il n’ouvre maintenant qu’un seul fichier et non un par thread.
  5. xtremweb.gmond.pl a été corrigé et “scale” mieux
  6. les certificats n’ont plus de dates de fin (pour faciliter le déploiement)
  7. xwconfigure corrigé : la génération des fichiers de configuration a été améliorée
  8. installeurs linux corrigés
  9. les scripts ont été corrigés : l’usage de “type” a été amélioré
  10. le scheduler rafraichit sa liste des tâches avec les PENDING seulement
• Nouvelle fonctionnalité
  • -AUCUNE-

• Corrections
  1. Launcher corrigé : il ne démarre plus si la clé SSL est incorrecte ou si l’URL est malformé.
  2. La gestion des paths a été corrigé dans le Launcher
  3. les messages d’erreur du worker sont plus détaillés.
  4. le worker a été corrigé: en cas de problème réseau au moment où le worker envoyait un résultat, le résultat était perdu et le worker n’etait plus capable de redemander un nouveau job.
  5. gestion des paths améliorée dans xwconfigure
  6. xwhep.bridge.pl modifié : il peut désormais se connecter directement à MySQL et n’est donc plus oblige d’utiliser le client XWHEP (on espère un gain de performances)
  7. xtremweb.gmond.pl : connexions MySQL corrigées
  8. un bug résolu au niveau du serveur : les connexions MySQL étaient mal fermées; on pouvait se retrouver avec énormément de sockets en TIME_WAIT
  9. un bug résolu dans la librairie E/S : tous les handlers sont maintenant correctement fermés en cas d’erreur/exception
  10. un bug résolu dans le cache : il ne peut plus contenir plus de 10k entrées
  11. les scripts ont été glabalement corrigés : il est préférable d’utiliser ‘type’ et non ‘which’ dans les scripts bash/sh
  12. du côté du client, xwchmod accepte aussi les UID (et pas seulement les URI)
  13. build corrigé : il génère correctement la version x86_64
  14. on n’utilise plus String.intern() parce que cela peut générer des exceptions “OutOfMemory in PermGen” (Cf http://www.codeinstructions.com/2009/01/busting-javalangstringintern-myths.html)
  15. les utilisateurs admin et worker public ne sont plus inséré dans aucun groupe (parce que ca n’était pas utilisé et pouvait porter à confusion)

• Nouvelles fonctionnalités
  aucune

• Corrections
  1. enregistrement des workers améliorée : on garde la version des workers
  2. un bug corrigé dans l’ordonnanceur : il ne parcourait pas la liste complete des tâches
  3. des bugs résolus dans xtremweb.ganglia :
     • les process “forkés” terminent maintenant correctement;
     • utilisation du champ “isdeleted” dans les tables DB
  4. xwhep.bridge.pl corrigé et légèrement modifié : n’est plus considéré comme erreur le fait qu’un pilot job n’execute pas de tâche (Cf XWHEP-5.7.2, point 8)
  5. des bugs corrigés dans le worker Win32 dans l’utilisation des paths et de l’option java -Xrs (Cf http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html)
  6. un bug corrigé dans le launcher : il ne doit pas effacer les JAR de mise à jour
• Nouvelles fonctionnalités
  1. des scripts SQL pour vérifier l’état de la plate-forme à travers la DB
  2. des scripts pour upgrader la DB

• Corrections
  1. un bug corrigé dans la définition de la base de données
     • la longueur des champs et “hosts.natedipaddr” sont maintenant 50 (et non 20) pour permettre de stocker des adresses IP V6
     • introduction d’une nouvelle table “Version” qui contient l’historique des version installées
     • un nouveau champ “hosts.pilotjob” permet de déterminer si un worker s’exécute sur une ressource de type SG (ex : EGEE)
     • le script xwsetupdb.sql modifie les tables en conséquence
     • le script xwconfigure modifie les tables de manière non destructive
  2. un bug corrigé dans la génération des dates sotckées dans la base de données (date d’insertion, date de completion etc.)

• Corrections
  1. un bug corrigé dans le bridge
  2. les installeurs Linux RPM et DEBIAN, ainsi que Mac OS X écrivent désormais leurs logs dans le répertoire /var/log
  3. la gestion des variables de configuration a été améliorée
  4. la variable KeyStore n’était pas correctement initialisée; elle peut désormais être indiferemment lue du fichier de configuration ou du paramètre Java -Djavax.net.ssl.keyStore
  5. un bug a été corrigé dans la gestion des erreurs MySQL
  6. l’utilisation des groupes de job a été corrigée
  7. un bug a été corrigé au niveau de l’ordonnanceur
  8. l’utilisation des certificats X509 a été modifiée conformément aux décisions prises par EDGeS.
     Le client vérifie maintenant automatiquement le contenu de la variable d’environnement $X509_USER_PROXY; le paramètre “–xwcert” n’est donc plus nécessaire
     En utilisant “–xwcert”, le certificat doit être valide, à défaut de quoi le job n’est pas soumis.
     Si le certificat décrit par $X509_USER_PROXY n’est pas valide, le job est soumis sans certificat. Tout worker, même s’il n’est pas un Pilot Job sur EGEE, peut désormais exécuter un job, même s’il a été soumis avec un certificat.
     Les Pilot Jobs sont des workers privés et peuvent donc exécuter tout job du propriétaire du certificat.

     Les workers (même les Pilot Job soumis sur EGEE) ne téléchargent jamais de certificat X509.
     Seul le bridge télécharge les certificats pour soumettre les pilot Job sur EGEE.

  9. Un bug a été corrigé dans la gestion des handlers de communications (ce qui a permis d’intégrer ADICS)
• Nouvelle fonctionnalité
  1. XWHEP intègre le protocole ADICS de l’Université de Cardiff.
     Cf http://www.p2p-adics.org.
     Ceci est donc une nouvelle fonctionnalité “externe” :
     • l’intégration de nouveau protocoles dans XWHEP existe en effet depuis longtemps
     • nous restons donc dans la branche 5.7.x

• Note : cette version est nommée 5.7.1 et non 5.6.4 parce que la version 5.6.3 a introduit une nouvelle fonctionnalité et aurait du être nommée 5.7.0.
  Je corrige donc cette erreur de versionning ici.

• Corrections
  1. xwconfigure boucle désormais jusqu’à ce que l’utilisateur donne une valeur correcte.
  2. La création des fichiers archives a été corrigée:
     *ps les fichiers *PS étaient exclus de l’archive ce qui excluaient "xwapps", "xwgroups" etc.

  3. les scripts du worker pour Mac OS X ont été corrigés
  4. les installeurs pour Mac OS X ont été corrigés. Les erreurs étaient dues à l’utilisation de NetInfo qui n’est plus supporté depuis Mac OS 10.5. NetInfo est maintenant remplacé par Directory Service qui est compatible 10.4 et 10.5. Nous avons testé 10.4.11 et 10.5.7.
  5. la gestion des paths a été corrigé sous Win32
  6. les projets Win32 innoSetup ont été corrigés

• Corrections
  1. Afin d’éviter d’éventuelles confusions entre XtremWeb et XWHEP, ce dernier installe désormais ses paquets dans /opt/XWHEP-server, /opt/XWHEP-worker and /opt/XWHEP-bridge. Les paquets XWHEP (Debian, RedHat, Apple) installent les paquets XWHEP-quelquechose et non plus xtremweb-quelquechose. Les fichiers qui existaient avant cette release (les scripts, les fichiers de configuration etc.) gardent leur “ancien” nom (xtremweb.quelquechose) pour ne pas perturber ceux qui ont déjà développé avec XWHEP.
  2. les timeout des sockets est nul par défaut
  3. HTTPLauncher, qui télécharge automatiquement la dernière version du middlewareavant de démarrer le worker a été corrigé : il utilise maintenatn le fichier le plus récent présent sur le disque local; il s’arrête immédiatement s’il ne peut accéder au disque local; l’utilisation de l’option java “-server” aété corrigée.
  4. des “deadlocks” ont été corrigé, au niveau du server.
  5. un bug a été corrigé au niveau de la gestion des noms des applications
  6. le worker garde maintenant son UID afin d’éviter de remplir inutilement la DB du server
  7. les installeurs ont été corrigés (RPM, DPKG, Apple PKG)
• Nouvelle fonctionnalité
  1. le worker peut maintenant prendre en charge des applications et leurs librairies dynamtiques

• un bug a été résolu au niveau de l’utilisation des URI.

• la distribution binaire a été corrigée et augmentée; elle prépare les paquets RPM, Debian et Apple pour le serveur, le worker et le client;
• un bug corrigé au niveau du client quant à l’envoi des fichiers associés aux jobs.

• cette version règle le problème de la mise à jour de la plate-forme en réintroduisant le launcher;
• cette version est la première à fournir un paquet "binaire".

• un bug a été résolu au niveau du serveur : la consommation mémoire a été améliorée.

Les deux figures montrent la quantité de mémoire utilisée par le serveur. La 1ere figure montre une voracité croissante avec la version 5.4.0: après quatre jours, la quantité de mémoire allouée s’élève à 382Mb. La 2nde figure montre une consommation plus raisonnable avec la version 5.5.0: après six jours, la quantité de mémoire allouée est trois fois moins importante.

• un bug a été corrigé au niveau de la couche des entrées/sorties

• au niveau du serveur, les dates des évènements sont maintenant correctes (date de soumission, date d’exécution, date de résultats…)
• un bug a été corrigé au niveau du bridge.

• dans le serveur, un bug a été corrigé au niveau des communications; le serveur de communication ne se fige plus.

• le bridge envoit désormais un signal au serveur à des fins de monitoring;
• un nouveau script xtremweb.jra2 permet de monitorer un ensemble de serveurs XWHEP installés; ce script a été spécialement développé pour le JRA2 de EDGeS;
• dans le serveur, un bug a été corrigé au niveau des communications; il semblerait que la gestion des méthodes synchronisées soit dépendant de la JVM utilisée;
• les scripts de lancements des différentes commandes du client ont été nettoyés;
• la page de configuration du worker peut être utilisée pour gérer un parc local de workers.

• La passerelle EDGeS de XWHEP à EGEE permettant l’utilisation de ressources EGEE est operationnelle; elle peut être monitorée ici.

• le serveur gère désormais un pool de connexions afin d’en gérer jusqu’à 500 simultanément; s’il y en a plus, elles sont mises en attente. Ceci permet d’éviter d’éventuels manques de mémoire;
• le client admet une nouvelle option –xwxml : elle permet de fournir un fichier XML en entrée;
• la couche de communication a été simplifiée : il n’y a plus qu’un seul message send pour tous les types d’object;
• le bridge a été stabilisié.

• un bug corrigé au niveau du worker relatif à la préparation du répertoire de travail des jobs.

• les clients peuvent maintenant se connecter à plusieurs serveurs; pour cela:
  • le client ne contient plus de passphrase et n’essaie plus de coder les mots de passe;
  • les mots de passe ne sont donc plus codés dans le fichier de config, ni que dans la base de données;
  • ceci n’introduit pas de trou de sécurité car les communications sont cryptées; il est de la responsabilité de l’utilisateur d’assurer l’intégrité de son fichier de config;
  • pour finir, ceci allège la compilation et l’installation qui n’a plus besoin de SQL.
• un bug a été corrigé au niveau du worker dans le téléchargement des donnéees;
• les notions de groupes et de sessions de jobs ont été réintroduites.
  Les groupes et les sessions permettent d’aggréger un ensemble de jobs.
  La seule différence réside en ce que les sessions sont automatiquement détruites quand le client se déconnecte (il se déconnecte en s’arrêtant ou quand change d’utilisateur);

• la GUI du client ne permet plus la selection de plusieurs lignes (par ex pour effacer les lignes ou pour télécharger les résultats). Ceci est du à un bug dans le table sorter. Cette erreur sera corrigé en portant notre logiciel sous Java 6 qui introduit des table sorter natifs;
• notre package est maintenant compatble Java 6 sans en utiliser les nouveautés (voir ci dessus); il est aussi compatible 64 bits.

• dans le fichier de configuration, SSLKeyStore peut maintenant être un chemin relatif;
• les propriétaires des ressources volontaires peuvent configurer leur worker en ouvrant la page http://localhost:4324;
• la gestion du cache a été améliorée et légèrement modifée :
  • de manière générale les informations présentes dans le cache ne sont pas retéléchargées depuis le serveur; à trois exception près : les works, tasks et hosts qui sont toujours rechargés depuis le server, car ce sont des informations susceptibles de changer souvent;
  • le client garde son cache entre deux exécutions. Une nouvelle commande xwclean permet de nettoyer le cache local; cette commande est disponible dans le menu Comm de la GUI.
  • le worker efface toute trace du disque local avant de s’arreter; il ne garde donc pas de cache entre deux exécutions;
• un bug a été résolu au niveau du serveur : la consommation mémoire a été améliorée.

Le fichier JAR est disponible. Pour mettre à jour, vous devez:

• copier le fichier JAR dans le répertoire lib et redémarrer votre serveur;
• copier le fichier JAR à l’endroit défini par la variable launcher.url, dans le fichier de configuration du worker; les workers le téléchargeront automatiquement à leur prochain lancement.

Les deux figures montrent la quantité de mémoire utilisée par le serveur. La 1ere figure montre une voracité croissante: après seulement 1H30, la quantité de mémoire allouée s’élève déjà à 78Mb. La 2nde figure montre une bonne stabilité: après plus de deux heures, la quantité de mémoire allouée n’a pas bougé de son niveau initial de 31Mb.

• utilisation des proxy de certificat X509 pour l’utilisation de ressources de grilles institutionnelles;
• la synchronisation a été améliorée : tout message attend maintenant une réponse du serveur;
• la dégradation des performances constatée au niveau du serveur a été corrigée.

Les deux figures montrent la réception de 1000 soumissions par le serveur. La 1ere figure montre clairement une dégradation des performances; elle disparait dans la 2nde figure avec les corrections.
Le temps total d’exécution est 2.5 fois supérieur car les messages attendent maintenant tous une réponse du serveur : ceci améliore la cohérence de la plate-forme.

• l’ordonnancement des tâches a été modifié afin d’ameliorer les performances. Ce n’est plus du simple round-robin: l’ordonnanceur fouille la liste des tâches en attente afin d’essayer de trouver un qui corresponde à la demande du worker;
• le script de test a été modifié : il soumit aussi des tâches de groupes.

La commande SQL suivante permet de mieux voir les résultats

select apps.name as app,label,
hex(works.accessrights),hex(apps.accessrights),
works.status,users.login as worker_login,
users.rights as worker_level
from
works,apps,tasks,hosts,users
where
works.appuid=apps.uid and
works.uid=tasks.uid and
tasks.hostuid=hosts.uid and
hosts.owneruid=users.uid
order by works.label;


On voit que le worker public (dont le login est worker) n’a pris en charge que des jobs publics (dont le label est public…); les workers privés (dont les logins sont user…) n’ont pris en charge que les jobs leur appartenant (dont les labels finissent par leur login).

“

• des bugs résolus dans la gestion du cache;
• des bugs résolus au niveau du serveur dans la gestion des utilisateurs et des applications;
• des bugs résolus dans la GUI du client;
• des bugs résolus dans l’utilisation de la clé électronique du serveur.

Le server est désormais certifié par une clé autosignée générée par createKeys. La prochaine version permettra d’utiliser des certificats X.509 certifiés par une CA.

Pour installer cette version, il est nécessaire de réinstaller la base de données.

L’installation et le déploiement nécessitent les actions suivantes dans cet ordre précis (createKeys doit être exécuté avant install).

$> make removeDB
$> make installDB
$> make clean
$> make
$> make createKeys
$> make install


Pour un déploiement de production, les clés ne doivent être générées qu’une seule fois; la regénération des clés nécessite un redéploiement complet de la plate-forme.

L’utilisation de SSL a un coût en termes de communication dans un rapport de un à deux. La figure de gauche montre le nombre de paquets TCP sans utiliser SSL; la figure de droite montre le nombre de paquets TCP pour la même commande en utilisant SSL :

Un script de test de la plate-forme est fourni dans le répertoire bin de l’installation

$> xtremweb.tests.pl


L’utilisation de ce script nécessite les droits administateur au niveau de la plate-forme (le fichier de config crée à l’installation poossède ces droits).

Ce script éxecute les commandes suivantes:

• insertion d’une application publique
• insertion de deux groupes d’utilisateur
• insertion 6 nouveaux utilisateurs : deux utilisateurs par groupe et deux utilisateurs hors de tout groupe
• insertion d’une application privée par utilisateur
• insertion de 12 jobs : un job public et un job privé par utilisateur
• lancement de workers
• monitoring des jobs

A la fin du script, nous pouvons constater que tous les jobs sont COMPLETED. On peut vérifier la bonne exécution du test avec la commande SQL suivante (nous ne pouvons utiliser le client pour cette vérification, car il n’affiche pas l’identité des workers dans la liste des jobs) :

select works.status,works.label,hosts.name,users.login
from users,works,tasks,hosts
where tasks.uid=works.uid
and tasks.hostuid=hosts.uid and
hosts.owneruid=users.uid
order by users.login;


La figure suivante montre le résultat de l’auto test.

On voit que le worker public (dont le login est worker) n’a pris en charge que des jobs publics (dont le label est public…); les workers privés (dont les logins sont user…) n’ont pris en charge que les jobs leur appartenant (dont les labels finissent par leur login).

“

Un bug a été résolu dans le worker, au niveau de la gestion de l’entrée standard (stdin) de l’application utilisateur.

Il reste toutefois un problème non résolu si cette application tente de tester la disponibilité de données dans stdin. Il y a alors une grande chance que la plate-forme n’ai pas eu le temps de positionner correctement stdin.

Ce problème est du au language Java utilisé pour développer notre plate-forme.

L’application utilisateur ne doit donc pas tester la disponibilité de données sur stdin, mais se contenter de le lire. Dans le cas où stdin est optionnel, il faut alors modifier l’application afin qu’elle prenne ses éventuelles données depuis un fichier texte.

Exemple:

L’exemple suivant marche correctement si myApp ne teste pas stdin:


$> myApp < aFile


Si stdin est optionnel, il faut modifier l’application afin de lui fournir ces données optionnelles depuis un fichier texte; par exemple:


$> myApp -f aFile


Désolé pour les inconvénients.

• introduction de la gestion des proxy de certificat X.509
• un bug a été résolu au niveau du téléchargement des données.

Pour installer cette version, il est nécessaire de réinstaller la base de données

$> make removeDB
$> make installDB
$> make install


• un bug résolu au niveau du worker dans la gestion des erreurs
• un bug résolu au niveau des entrées/sorties
• la page HTML du worker est maintenant configurable
• les performances ont été améliorées dans un rapport de 1 à 14 grâce à une meilleure utilisation des caches

  Les graphes ci dessous montrent deux soummissions de 1000 jobs. Nous voyons que la résolution du bug des E/S et l’utilisation du cache permettent de faire quatre fois moins d’appels internes pour un temps d’exécution 14 fois plus rapide.

  
  

Un bug majeur résolu au niveau du serveur dans la gestion des tâches

Trois bugs corrigés

• l’output config quand on insere un nouveau user;
• le téléchargement des tasks;
• l’URI des datas.

Du nettoyage mineur

Un bug a été résolu dans le protocole de stockage des résultats.

Un bug a été résolu au niveau du client, dans la soumission des données.

Un bug a été résolu au niveau de l’accès à la base de données.

Nous n’utilisons plus log4j, car nous suspectons des fuites de mémoires.

Un bug résolu au niveau de l’upload des résultats par le worker.

Un bug résolu au niveau des communications.

Un bug résolu au niveau du worker.

Le client récupère correctement les résultats.

Lors de la soumission, on peut maintenant fournir directement un fichier d’environnement; le client crée automatiquement la donnée correspondante.

• synchronisation inter threads au niveau du serveur;
• résolution des IP publiques/privées.

• le worker public possède les droits d’utilisateur "WORKER_USER"; il ne peut prendre en charge que des jobs publics (des jobs dont les droits d’accès contiennent o+rx);
• le worker de groupe est un worker public (droit utilisateur "WORKER_USER") inséré dans un groupe; il ne peut prendre en charge que des jobs du groupe (des job dont les droits d’accès contiennent g+rx);
• le worker privé est worker non public (qui n’a pas les droits utilisateurs "WORKER_USER") et ne peut prendre en charge que les jobs de son propre utilisateur (des jobs dont les droits d’accès contiennent u+rx)