Archive

Posts Tagged ‘Java’

Langages : le choix d’ORDINAL pour COOX apparaît judicieux

Le graphe ci-dessous représente le graphe d’utilisation des différents langages par les utilisateurs de la plateforme de développement GitHub (utilisée entre autres par PAYPAL et SAP).
A rapprocher également du classique index TIOBE, plus général, où Java est en première place avec 17,8 % (+1,7 % depuis juin 2014). Toujours pour l’ensemble des logiciels utilisés sur la plateforme GitHub, Visual Basic et Visual Basic.NET totalisent à eux 2 moins de 5%.
Pour son développement et ses extensions, COOX s’appuie sur deux langages très complémentaires, le Java et le JavaScript. Très rigoureux et référence des langages objets, Java dote la plateforme COOX d’une architecture logicielle solide, pensée pour l’Intranet et le déploiement sans installation des clients. Le JavaScript, quant à lui, compagnon fidèle de toutes les pages HTML du web, est un langage très souple, facile à apprendre, et moins exigeant vis à vis du développeur. Il permet en outre de faire des modifications « à la volée », sans recompilation et donc sans nécessiter d’arrêter les applications.

graphe

De nouveaux langages sont lancés chaque année, promettant des temps de développement record et de nouvelles fonctionnalités. Mais leur succès risque de s’éteindre aussi vite qu’il s’est déclaré…
Pour son développement et ses extensions,  COOX s’appuie donc sur deux langages très complémentaires, le Java et le JavaScript…

Ayant pressenti le potentiel de ces deux langages, ORDINAL Software les a choisi en 2000 lors du lancement des développements de sa plateforme COOX. Ces choix ont été confirmés par l’évolution de la diffusion des des langages informatiques ces dernières années. C’est une sécurité et une pérennité supplémentaire pour les industriels.

En effet, même si le progiciel COOX privilégie le paramétrage, de manière à diminuer les temps de développement et les sources d’erreurs, il ne pourrait être considéré comme une solution logicielle ouverte sans disposer d’un langage d’extension des applications par programmation. Choisir ce ou ces langages n’est pas une chose simple, en particulier pour les applications industrielles, où une forte pérennité des installations est souhaitée.

Approfondir le sujet : le langage de votre application industrielle est-il important ?

Le langage de votre application industrielle est-il important ?

D’environ une dizaine au début des années quatre-vingt, les langages informatiques se sont multipliés et leur nombre dépasse aujourd’hui largement la centaine.Les langages informatiques
Ils font l’objet d’une littérature abondante qui a conquis sa place dans les rayonnages des grands librairies aux côtés des mathématiques, de la physique, de l’économie, de l’histoire, de la philosophie et des sciences humaines.
Assez régulièrement, ils sont au cœur de débats parfois virulents sur la suprématie de tel ou tel langage, censé reléguer les autres dans la préhistoire.
Soyons clairs, la plupart du temps, ces débats n’intéressent que les informaticiens et même une toute petite partie d’entre eux. Mais il arrive aussi que ce débat arrive sur le devant de la scène, parce que les concepts d’un langage semblent susceptibles de changer profondément la manière de programmer et son efficacité, ou parce que l’on prend brusquement conscience qu’un langage est désormais utilisé sur des millions, voire des milliards d’appareils.
LIRE LA SUITE

COOX en bref : 5 raisons pour vous industriels d’utiliser COOX

Plateforme COOX et ses modules correspondants

COOX en 5 points : bénéfices pour l’utilisateur final

ScreenClip Produisez, c’est tracé !
       Un concept unique : une traçabilité automatique du procédé et des produits couplée au process : plus dynamique, plus fiable, et qui en suit les évolutions.
Au delà du simple respect des exigences, vous disposez…Lire la suite

ScreenClipUn faible coût de développement et d’intégration
Grâce aux modules métier prêts à l’emploi MESbox, autonomes et extensibles, la majeure partie de vos besoins fonctionnels est couverte par simple paramétrage, sans développement
informatique. La solution est installée rapidement… Lire la suite

ScreenClip

Capitalisez le savoir-faire de vos usines !
La technologie de modélisation des équipements et des opérations de COOX vous permet d’emmagasiner votre savoir-faire en matière de fonctionnement…Lire la suite

ScreenClip

Un seul logiciel à installer et à maintenir, et des opérateurs formés rapidement
Rassemblant sur une plateforme unique, entièrement intégrée, les modules de supervision (SCADA) et de suivi de production (MES), COOX permet de répondre à l’ensemble de vos besoins d’informatique industrielle avec un seul logiciel. Quelle que soit…Lire la suite

ScreenClipAccédez immédiatement à vos applications depuis tout point de l’usine, et au delà
L’architecture Java 100% Intranet de COOX permet l’accès sans installation spécifique depuis nimporte quel PC et depuis des terminaux mobiles…Lire la suite

Comment diagnostiquer les problèmes liés aux fuites mémoire avec la plateforme COOX ?

Outils de diagnostic d’une fuite mémoire 

Mémoire
La mémoire est une ressource limitée ! et en java, lorsque la JVM n’a plus assez de mémoire pour s’exécuter, elle génère une Erreur java.lang.OutOfMemoryError.
Plusieurs cas de figure sont alors envisageables :
– Soit vous n’avez pas alloué assez de mémoire à la JVM
– Soit le système a, ce que l’on appelle, une fuite mémoire

Si vous êtes dans le 1er cas, les choses se résolvent assez facilement : il suffit d’allouer plus de mémoire grâce au paramètre -Xmx, et le tour est joué !
Dans le second cas, il va falloir déterminer d’où vient la fuite mémoire.

Mécanisme du ramasse-miettes (Garbage Collector)
Cet élément contribue à la robustesse et à la performance des programmes. Le ramasse-miettes est appelé régulièrement et automatiquement pendant l’exécution du programme.
Sur les systèmes multi-processeurs et/ou multi-cœurs, celui-ci emploie même des threads multiples à faible priorité afin de perturber le moins possible l’exécution de programme.
En outre, le programmeur peut au besoin suggérer de lancer le ramasse-miettes à l’aide de la méthode System.gc().

Un grief récurrent à l’encontre de langages comme C++ est la lourde tâche d’avoir à programmer manuellement la gestion de la mémoire. En C++, la mémoire allouée par le programme pour créer un objet est désallouée lors de la destruction de celui-ci (le plus souvent par un appel explicite à l’opérateur delete). Si le programmeur oublie de coder la désallocation, ceci aboutit à une « fuite mémoire », et le programme en consomme de plus en plus. Pire encore, si par erreur un programme demande plusieurs fois une désallocation, ou emploie une zone de mémoire après avoir demandé sa désallocation, celui-ci deviendra très probablement instable et se plantera.

En Java, une grande partie de ces problèmes est évitée grâce au ramasse-miettes. L’espace mémoire nécessaire à chaque objet créé est alloué dans un tas de mémoire en anglais : memory heap, réservé à cet usage.
Le programme peut ensuite accéder à chaque objet grâce à sa référence dans le tas. Quand il n’existe plus aucune référence permettant d’atteindre un objet, le ramasse-miettes le détruit automatiquement — puisqu’il est devenu inaccessible — libérant la mémoire et prévenant ainsi toute fuite de mémoire.

Le ramasse-miettes emploie un algorithme de marquage puis libération – en anglais –  : mark and sweep qui permet de gérer les cas complexes d’objets se référençant mutuellement ou de boucles de références (cas d’une liste à chaînage double par exemple).
En pratique il subsiste des cas d’erreur de programmation où le ramasse-miettes considèrera qu’un objet est encore utile alors que le programme n’y accèdera plus, mais dans l’ensemble, le ramasse-miettes rend plus simple et plus sûre la destruction d’objets en Java (en supprimant la nécessité de placer au bon endroit du code l’appel à l’opérateur delete).

Diagnostic
Afin de nous aider à analyser et diagnostiquer avec vous les problèmes liés aux fuites mémoire, voici quelques outils à mettre en place qui vous permettront de collecter les informations nécessaires pour cette étude :

  • Le diagnostic tool

La plateforme COOX 7 Helium propose l’outil « Diagnostic tool » pour faciliter la collecte et l’envoi d’informations au support technique. Cet outil peut s’installer sur nimporte quelle machine (voir COOX-DOC-Platform).
Vous pouvez alors nous faire parvenir les éléments lorsque le figeage se produit, en nous précisant la date et l’heure dudit événement.

tool

N’oubliez pas de cocher « collecter le heap dump des serveurs »

Le heap dump des serveurs :
Collecter le heap dump des serveurs revient à exporter le contenu mémoire des JVM des serveurs. Cela permet notamment de diagnostiquer plus facilement les problèmes de débordement mémoire. Toutefois, si cela n’est pas nécessaire, ne le cochez pas systématiquement car les dumps mémoire augmentent grandement le temps de collecte des informations.

  • Heap dump automatique du serveur

Dans le cas où le diagnostic tool n’arrive pas à se connecter au serveur, n’oubliez pas de prendre une capture de la console de cet outil et de nous l’envoyer.
Un autre outil peut être alors utilisé : le dump auto. Le principe consiste à demander à la JVM de faire un Heap dump automatiquement quand on arrive au fameux OutOfMemoryError !
Les deux options à utiliser sont les suivantes :

-XX:+HeapDumpOnOutOfMemoryError : active le dump automatique
-XX:HeapDumpPath : spécifie le fichier d’export

Exemple de modification du fichier manager.properties :
args=-Dswing.aatext\=true -Xmx1G -XX\:PermSize\=256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:\\tmp\\mydump.hprof -cp .;system\\* globalscreen.startManager

 Cet outil peut être aussi bien utilisé en COOX 6.01, COOX 6.02 qu’en COOX 7 Helium.

  • VisualVM

Visual VM est un outil de monitoring de JVM locale ou distante. Il est intégré au JDK depuis la version 6 update 7. Vous le trouverez dans le répertoire JAVA_HOME/bin/jvisualvm
Il permet notamment :
– de connaître l’occupation CPU, la taille de la heap, le nombre de threads ainsi que le nombre de classes chargées de la JVM. On peut suivre l’évolution dans le temps de ces métriques.
– de réaliser un dump des threads en activité et de la heap.

  1. Faire un Heapdump du poste serveur avec VisualVm au moment du figeage

heapdump

Dans le cas de l’image ci-dessus le poste serveur est le 192.168.0.107

2. Enregistrer des Snapshots

Visualvm permet avec les plugins de prendre des snapshots de la mémoire (avec le graphe de tous les objets)

Génération d’un Snapshot :

snapshot

Exploitation et enregistrement d’un Snapshot :

snapshot1

snapshot2

 

Plateforme COOX : Quelles sont les options des clients COOX via un navigateur ou via Java Web Start ?

COOXCOOX permet de lancer un client en mode applet (une applet Java est exécutée au sein du navigateur internet),

Navigateur

ou via un client Java Web Start (le client est alors une application indépendante du navigateur internet).

Java Web Start

Les options :

fullscreen=yes Pour lancer le client en mode plein écran
xmx=512 Pour fixer la mémoire maximale autorisée à 512Mo
clientType=cm Pour définir le type du client, saisissez une des options (cs, cm, ct),
par défaut votre client est de type Superviseur (cs)
relaunchview=myView Pour forcer une vue à s’ouvrir quand le client se relance en cas de déconnexion
lang=en Pour définir la langue de l’application (ici anglaise)
touch_input=true Pour activer la saisie tactile
login=myLogin&passwd=myPassword Pour forcer un utilisateur

 

 

Étiquettes : , , ,
%d blogueurs aiment cette page :