Lancer tomcat en debug

Souvent il m’arrive d’avoir a me connecter en debug sur la plateforme de recette.

Dans mon cas la machine est sous windows,

dans tomcat/bin, copier/coller startup.bat en debug.bat

modifier le fichier,

après la ligne :

set "EXECUTABLE=%CATALINA_HOME%\bin\catalina.bat"

ajouter :

set JAVA_OPTS=%JAVA_OPTS% -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000

Faire une recherche case insensitive mariadb

Parfois il nous arrive de vouloir faire une recherche sur un champ en ignorant la case.

La mauvaise façon de le faire serait :

SELECT * FROM table WHERE upper(champ) = upper(‘morgan’);

Faire ceci est catastrophique en terme de performance, et en plus, si jamais on met un index sur le champ, il ne pourra pas fonctionner car les index sont sensible a la case.

Heureusement les sgbd modernes viennent avec des solutions. Pour mariaDB/Mysql on peut simplement utiliser un collate différent. Les collates finissant par _bin sont case sensitive et _ci sont case insensitive.

SELECT * FROM table WHERE champ = ‘morgan’ COLLATE utf8mb4_unicode_ci;

Release d’une librairie au file de l’eau pour jenkins et maven

En ce moment je suis sur des problèmatiques de release avec mon projet maven.

Je voudrais que mon job jenkins soit capable de releaser automatiquement une version et mettre à jour les projets qui l’utilise comme dépendance.

Pour cela il y a deux petites commandes cli très utile. Mais d’abord, étudions comment structurer sont pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>

<groupId>com.wps.invoicing</groupId>
<artifactId>mp-invoicing</artifactId>
<version>6.1.1-SNAPSHOT</version>
<packaging>jar</packaging>

<name>Marketplace Invoicing</name>
<url>http://maven.apache.org</url>

<properties>
<majeur.version>6.1</artemis.version>
<patch.version>1</patch.version>
</properties>
</project>

Ici, la version majeur est variabilité et ne seras changé que sur les branches de releases. Par contre, la version patch va être incrémenter programmatiquement via le JenkinsFile.

Première commande, mettre le projet en version définitive :

 mvn versions:set -DnewVersion='${majeur.version}.${patch.version}'

1	mvn versions:set -DnewVersion='${majeur.version}.${patch.version}'

puis commiter les changements

mvn versions:commit

1 2	mvn versions:commit

Ensuite, il faut deploy la version sur nexus.

Maintenant que notre version N a été publier, il ne reste plus qu’a incrémenter la version patch.

def pom = readMavenPom file: 'pom.xml'
def incrementMinor = pom.properties['patch.version'].toInteger() +1

def pom = readMavenPom file: 'pom.xml'

def incrementMinor = pom.properties['patch.version'].toInteger() +1

Ensuite, il faut updater la propriété (toujours dans le jenkinsFile)

bat "mvn versions:set-property -Dproperty=patch.version -DnewVersion=${incrementMinor}"
bat "mvn versions:commit"

1 2	bat "mvn versions:set-property -Dproperty=patch.version -DnewVersion=${incrementMinor}" bat "mvn versions:commit"

Puis créer la nouvelle version snapshot, commit et deploy pour que tous les nouveaux projet l’ai

mvn versions:set -DnewVersion='${majeur.version}.${patch.version}-SNAPSHOT'
</code><br /><code>mvn versions:commit
</code><br /><code>mvn deploy

mvn versions:set -DnewVersion='${majeur.version}.${patch.version}-SNAPSHOT'

</code> <code>mvn versions:commit

</code> <code>mvn deploy

Jasper Report – Ajouter une interligne dans un tableau

Le but est de pouvoir ajouter une interligne dans un tableau. Cela peut-ête très utile, par exemple lors d’une facture et que l’on voudrais pouvoir préciser la taxe.

Pour ce faire, il faut faire des groupes dans le tableau. Don un group footer (qu’on va appeler « Group1 » car on a beaucoup d’imagination). A l’intérieur de ce groupe, on va ajouter un texteField (qui s’appel ici compléments).

A ce stade, lorsque vous allez générer le pdf, la ligne sera afficher uniquement tout en bas du tableau, comme un footer.

Et c’est ici que réside l’astuce, il faut définir le group1 comme étant la concaténation de tous les champs de la colonne. Ainsi, chaque nouvelle ligne sera considéré comme un nouveau group et l’interligne sera répété.

En bonus, je vous met la définition du groupe de donnée (subDataSet) .

 &lt;subDataset name="FACTURE_LIGNE_DETAIL" uuid="d6f6b8e3-dd07-442d-a637-1f0536066d26"&gt;<br />&lt;parameter name="PIECE" class="com.fdilogbox.artemis.jreport.bean.marketplace.StandardReportParam"/&gt;<br />&lt;field name="reference" class="java.lang.String"/&gt;<br />&lt;field name="description" class="java.lang.String"/&gt;<br />&lt;field name="quantite" class="java.lang.String"/&gt;<br />&lt;field name="unitOfMeasure" class="java.lang.String"/&gt;<br />&lt;field name="prixUnitaireHT" class="java.lang.String"/&gt;<br />&lt;field name="montantTotalHT" class="java.lang.String"/&gt;<br />&lt;field name="tauxTaxe" class="java.lang.String"/&gt;<br />&lt;field name="complements" class="java.lang.String"/&gt;<br />&lt;group name="Group1"&gt;<br />&lt;groupExpression&gt;&lt;![CDATA[$F{reference}+$F{description}+$F{quantite}+$F{unitOfMeasure}+$F{prixUnitaireHT}+$F{montantTotalHT}+$F{tauxTaxe}+$F{complements}]]&gt;&lt;/groupExpression&gt;<br />&lt;/group&gt;<br />&lt;/subDataset&gt;

Mettre à jour tous les dépot git d’un répertoire

Voici une petite astuce qui me permet de mettre à jour tous les dépots git d’un répertoire. Pratique quand on a plein de sous-dépot.

# For use in a shell:
# Download this file to /usr/local/bin/git-pull-recursive, then chmod 755 it to install git-pull-recursive
find . -type d -name .git -exec sh -c "cd \"{}\"/../ && pwd && git pull" \;

# For use in a shell:

# Download this file to /usr/local/bin/git-pull-recursive, then chmod 755 it to install git-pull-recursive

find . -type d -name .git -exec sh -c "cd \"{}\"/../ && pwd && git pull" \;

Étude technique

Comment choisir la base de donnée

Dans notre besoin, une base de donnée clés / valeur correspondrait à notre attente car nous aurions besoin d’une clé (id de la base alfresco) et d’une valeur (les métas du document).

En soi, une base de donnée relationnelle peut tout à fait faire le job : une colonne ‘alfrescoID’ indexée et une colonne ‘metadata’. Les dernières versions de bases relationnelles permettent d’avoir des colonnes de type json et donc introduisent le paradigme ‘document storage’ puisqu’il devient possible de requêter du json.

Avant de choisir le paradigme de la base de données dont nous avons besoin (relationnelle / clés/valeur / document / graph), il est important de savoir ou l’on doit se situer sur le théorème de CAP. Si nous n’avons pas besoin de partitionnement, une base relationnelle suffirait.

Comment savoir si une base relationnelle a besoin de partitionnement ? La réponse est simple : Si les indexes ne tiennent pas en RAM, les performances sont dégradés et on a besoin de les partitionner. A partir du moment où il y a besoin de partitionnement, il vaut mieux quitter les bases SQL conventionnelles pour aller vers les bases NOSQL.

Condition du benchmark

Pour le benchmark, nous allons comparer 2 bases relationnelles : mysql 5.8 (dernière version) et postgre 10.3 (dernière version).

Je vais générer 100 000 lignes, avec une colonne ‘dbid’ qui correspond a l’id dans la base alfresco et une colonne ‘data’ qui contiendra un json ~2MO.

L’idée est de vérifier l’empreinte mémoire utilisée par la base pour stocker les dbid/métadonnée d’un document.

Si l’empreinte mémoire est trop grande, il faudra songer à utiliser des bases NoSQL.

Les tests seront effectués sur un serveur avec les caractéristiques suivantes :

OS : windows server 2012 à jour
RAM : 64Go
Proc : 4 proc a 2.39GhZ
SSD 1To

C’est parti !

Étape 1 : installation

Installer un serveur postgresql 10 à été très facile, double clique sur l’exe, suivant -> suivant et tout fonctionne très bien.

Pour installer le serveur MySql c’est beaucoup plus laborieux, il faut installer toutes les dépendances .net

Étape 2 : Mesure de l’empreinte mémoire à vide

Je profite de ce chapitre pour dire qu’il est très difficile de mesurer l’empreinte mémoire utilisée par un service sous Windows.

Je m’y suis pris de trois manières différentes, mais aucune ne retourne le même résultat. Nous allons en étudier 2 des trois afin de ne pas noyer la lecture d’informations.

Méthode 1 : taskmanager

Ici on peut remarquer 2 choses :

1) A vide mysql consomme 340Mo , c’est probablement du au fait qu’il utilise .NET

2) postgresql utilise 8Mo et crée 2 processus par CPU, il est multi-threadé .

Methode 2 : moniteur de ressources

Ce que je ne comprends pas, c’est que les données (plage de travail) ne correspondent pas avec ce qui est affiché dans le taskmanager. enfin, passons !

L’avantage du moniteur, c’est qu’il te donne la ram allouable au processus (validation) et la mémoire réellement utilisée (plage de travail).

Pour mysql on voit que le processus a 498Mo de ram réservé pour lui et qu’il en utilise 368Mo.

Pour postgresql, si on additionne tout on est à 11.2 Mo de ram réservé et qu’il en consomme 246 Mo

Conclusion

Il semblerait que la méthode avec le moniteur de ressource soit plus fiable.

Étape 3 : Import des données (100 000 lignes)

Alors là, première surprise, avec un fichier JSON qui représente les méta-données d’un document, valide à la norme RFC, je peux l’importer dans une colonne JSON de postgresql mais impossible de l’importer dans une colonne json mysql, il lui trouve une erreur de syntaxe…

J’utiliserai donc un champ text afin de stocker le json pour mysql.

/!\ Les temps d’import sont ralentis par rapport a la réalité car le serveur mysql et postgre sont sur le même disque SSD. Donc ils sont potentiellement à multiplier par 2

L’import ayant commencé vers 15h13 et fini a 15h18 pour postgresql et 15h19 pour mysql.

-> mysql prend ~20/30% (a la louche) de temps en plus que postgresql sur l’insertion massive.

Wait … 1 minute de plus pour mysql et 30% de perf en moins ? Il y a pas quelque chose qui cloche ?

Si, postgresql a fini d’écrire sur le disque, donc la minute de plus qu’a pris Mysql, elle est a multiplier par 2.

Je dis 30% car j’ai vu la bar de progression qui était à 70% quand postgresql a terminé.

Étape 4 : Mesure de la mémoire après import de 100 000 lignes

Méthode 1 : taskmanager

Mysql : 469Mo

Postgresql : 8.3Mo (aucun changement)

Méthode 2 : moniteur de ressources

Mysql : 480Mo réellement utilisé

Postgre : 257 Mo réellement utilisé

Étape 5 : Import des données (1 000 000 lignes)

Import a débuté à 15:21.

Je suis allé au toilette et je suis revenu a 16h05,

l’import postgresql était terminé, pas celui de mysql …

16h17 : mysql vient de terminer l’import, encore une fois, il faut penser à multiplier le delta par 2 car il était tout seul à écrire.

Étape 6 : Mesure de la mémoire après import de 1 000 000 lignes

Mysql : 520Mo réellement utilisé

Postgre : 302 Mo réellement utilisé

Étape 7 : Vitesse de lecture

Faisons un « select count(*) from meta.metadata; »

mysql : 234 ms

postgre : 187ms

Postgresql est plus performant de 21% par rapport a mysql pour faire un count(*)

Étape 8 : Analyse des chiffres

100 000 lignes

Les chiffres bruts (du moniteur de ressource, que je juge plus fiable), PostgreSQL consomme 2 fois moins de ram que Mysql.

Si on s’intéresse aux delta des chiffres :

mysql prend 140 Mo pour indexer 100 000 lignes
postgresql prend 11 Mo pour indexer 100 000 lignes.

Ici c’est encore pire, mysql consomme 10 fois plus de ram que postgre pour les indexes.

1 000 000 lignes

Pour les chiffres brut, postgresql prend a peu près 2 fois moins de ram que mysql.

Quand on regarde le delta :

mysql prend 180Mo RAM pour stocker 1M lignes

postgre prend 56Mo RAM pour stocker 1M lignes

Postgresql consomme 3.2 fois moins de ram que Mysql.

Étape 9 : Conclusion

On se rend compte que la taille des indexes n’est pas linéaire. On voit que passé un certain cap il doit se passer de la compression en ram. A priori une base relationnelle simple, comme mysql suffirait pour stocker les métas des documents de 100 000 000 documents.

En revanche, l’étude met en exergue la supériorité de postgresql sur mysql en terme de performances

vitesse d’écriture : +30%
vitesse de lecture : +20 %
Consommation RAM : 2 fois moins d’espace total
les indexes consomment 3 fois moins de ram
multithreadé bien géré.

Expression du besoin fonctionnel

L’objectif est d’être capable de stocker 100 000 000 documents avec alfresco. On sait déjà que la base de donnée alfresco ne tiendra jamais la charge. Le but est donc de déléguer le stockage des méta-données à une base externe (laquelle ?) afin de décharger la base alfresco.

Il y a aussi un moteur d’indexation (solr) qui indexe tous les documents et qui effectue la recherche sur les méta-données. Ainsi le rôle de la base de donnée est de stoker la donnée et pas d’effectuer des recherches.

Une requête Solr renverra des ID de base de donnée mysql correspondant à cette recherche.

Pour soulager la base alfresco, il faudrait une seconde base de donnée qui fasse le mapping entre l’id de la base alfresco et les méta-donnée du document.

Théorie sur les bases de données

Théorème de CAP

Dans ce chapitre, nous allons faire un peu de théorie et étudier le théorème de CAP.

Consistency

C = Consistence = La donnée est fiable. Après un insert ou un update, quand on fait un read, on est certain que la donnée soit à jour.

Availability

A = Availability = Le fait que la base de donnée soit rapide à répondre (haute vitesse d’accès à la donnée).

Partitioning

P = Partitioning = Quand on a des grosses base de données, un seul serveur ne suffit plus pour tout stocker, il faut partitionner la donnée sur plusieurs serveurs.

Le théorème de CAP dit qu’il est possible d’avoir seulement 2 de ses trois choses.

Les bases de données relationnelles (postgresql, mysql) sont des bases de données CA (la donnée est rapide d’accès et toujours fiable) mais se scale très mal. Le partitioning n’est pas impossible, mais l’overhead de partitioning coute très cher.

A partir du moment il faut commencer à avoir un cluster, il faut songer à des bases de données AP ou CP.

Par exemple, mongoDB est une base de donnée CP : Elle est capable d’être clusterisée sans payer de gros overhead, et la donnée est toujours consistante. Après un update, la donnée est tout de suite mise à jour sur tous les clusters. Le coût a payer pour cela est une vitesse de lecture diminuée (availability).

D’un autre côté, il y a Cassandra : une basse de donnée AP. C’est à dire que Cassandra se clusterise très bien tout en gardant des vitesses d’accès comparables à des bases de données relationnelles. Le contre-coup à cela, c’est qu’un update peut mettre du temps à se propager aux clusters. Un appel read, juste après un update, peut ne pas renvoyer la donnée updatée mais l’ancienne valeur. L’ajout / modification / suppression de donnée devient asynchrone.

Pour les bases de données AP et CP, le fait d’être transactionnelle coute plus cher aussi. Garantir une transaction à travers tous les clusters est plus difficile que sur une seule machine.

Les différents modèles de base de données

Différents modèles de bases de données vont être étudier dans ce chapitre, pas seulement les bases SQL conventionnelles, mais aussi les bases noSql (not only sql)

Relationnel

Ce sont les plus connues, elles ont été évoquées plus haut. Les bases de données relationnelles fonctionnent avec des jointures. Le principe est d’éviter à tout prix de dupliquer la données. Pour cela, on va utiliser des jointures pour lier les données entre elles. On dit que les entités ont des relations entre elles (1 to n, n to 1, n to m, 1 to 1).

L’avantage de ce type de bases de données est que la donnée n’est pas dupliquée, elle prend moins de place sur disque. Le désavantage est que les relations entre les entités sont fortes, c’est pour cela que ce genre de base de données est difficile à scaller.

Clés / valeur

Ce genre de base de données est très adapté pour les technologies de caches. A partir d’une clé, on est capable de récupérer des données.

Le problème de ces bases de données est qu’on ne peut pas faire de requête avec critère de sélection, par exemple : « Donne moi toutes les clés qui contiennent un chat ». Ou alors si c’est possible, cela coute extrêmement cher en performance.

Document

Ce sont ces bases que je préfère. MongoDB est une base de données orientée document.

Avec ces bases de données, il faut penser complètement différemment des bases relationnelles. Par exemple, il ne faut pas avoir peur de dupliquer la donnée, et faire des relations entre les tables coute cher en performance car les notions de lazy loading n’existent pas (encore ?).

Ce type de base est très approprié si le produit n’est pas figé et que le modèle de donnée est amené à souvent évoluer.

L’approche est de faire des POJO en java, et les envoyer a la base de donnée qui les sérializera en json. On pourra faire des requêtes sur des propriétés json, etc …

Graph

Celles-ci, je les connais moins, j’ai un petit peu joué avec neo4J mais j’ai très vite été déçu du produit (par exemple il est difficile de stocker des HashMap). Il existe des domaines (notamment en statistique) où se représenter la donnée sous forme de graph permet une plus grande exploitation de la donnée, notamment en cherchant des voisins pas trop éloignés d’un nœud. C’est très utilisé pour les algorithmes de recommandation.