jeudi 18 mai 2017

Vert.X : "Don’t block the event loop", même en debug ?

Il y a une règle essentielle dans Vert.X. Elle est affichée, répétée dans la documentation, mais elle me gène pour debugger :

Don’t block the event loop

Voilà pourquoi, et comment j'ai contourné le problème...

Mes débuts en Vert.X

J'ai débuté récemment avec Vert.X 3, après avoir assisté à des conférences de Julien Viet, Clément Escoffier, Julien Ponge et Thomas Segismont. Ils sont tous les quatre français et font partie de l'équipe de développement de Vert.X.

J'ai été convaincu par leurs présentations. Si vous voulez jeter un coup d’œil, certaines sont disponibles en vidéo :

Non-bloquant

Je ne vais pas revenir sur les principes de Vert.X, c'est très bien expliqué dans les vidéos. Et je vous renverrai volontiers vers mon wiki sur lequel j'ai consigné mes notes d'apprentissage de Vert.X.

Ce qui m'a gêné c'est sa règle d'or  :

Don’t block the event loop


Je sais, je l'ai déjà citée, mais ils semblent vraiment y tenir chez Vert.X.


Ça signifie qu'il ne faut pas exécuter d'opération bloquante dans un verticle classique. Tout ce qui peut bloquer un thread sur une durée significative doit être fait dans un worker verticle ou appelé via vertx.executeBlocking().

Significatif ?

Pour Vert.X, une durée significative, c'est deux secondes.


C'est la valeur de la constante DEFAULT_MAX_EVENT_LOOP_EXECUTE_TIME dans VertxOptions. Et ça peut être modifié au démarrage.

Si on dépasse ?

Si le thread est bloqué plus de deux secondes, on peut avoir une alerte :
Jan 01, 1970 0:00:00 AM io.vertx.core.impl.BlockedThreadChecker
WARNING: Thread[vert.x-eventloop-thread-2,5,main] has been blocked for 3615 ms,
         time limit is 2000
io.vertx.core.VertxException: Thread blocked
    at ...

How cool is that ?

Je n'ai rien à redire à ce comportement, sauf en debug. Chaque point d'arrêt va bloquer le thread, et on va avoir une sortie standard polluée par le BlockedThreadChecker.

Pour éviter ça, on peut augmenter la valeur de maxEventLoopExecuteTime ou, mieux encore, augmenter le délai de vérification

  vertxOptions.setBlockedThreadCheckInterval(1_000_000L);

Uniquement en debug

Évidemment, je ne voudrais avoir cette ligne qu'en debug. Pour ça, je peux parcourir les arguments de démarrage et vérifier si -agentlib:jdwp est présent.


  if (ManagementFactory.getRuntimeMXBean()
                     .getInputArguments()
                     .stream()
                     .anyMatch(arg -> arg.startsWith("-agentlib:jdwp"))) {
      vertxOptions.setBlockedThreadCheckInterval(1_000_000L);
  }

Comme ça, je peux debugger sans être pollué par les alertes du BlockedThreadChecker, mais je les conserve en exécution normale.

Evidemment, si vous avez d'autres solutions à proposer, n'hésitez pas à partager.

Edit (18 mai 2017)
Lorsqu'on lance Vert.X en debug avec son plugin, il met MaxEventLoopExecuteTime à une valeur très élévée (environs 300 000 ans).

mercredi 4 janvier 2017

Le jour d'après MacBook

Le mois dernier, j'avais annoncé ma décision de remplacer mon Mac Book Pro par un laptop Linux. L'article avait suscité pas mal de réactions, ce qui me fait penser que je ne suis pas le seul à vouloir faire ça. Depuis, j'ai commandé et reçu un Dell Precision 5510.

Après avoir installé, configuré et testé ma nouvelle machine, je voulais raconter mes premières semaines. Si vous ne voulez pas lire la suite, je résume : ça s'est parfaitement bien passé. Mais en fait pas tout à fait.

vendredi 9 décembre 2016

MacBook, c'est fini

Mac c’est has been

Moi aussi je voulais être à la mode, j’ai donc décider de remplacer mon Mac Book Pro par un laptop Linux. Par contre, je ne suis sûr d’avoir exactement les mêmes raisons que la vague actuelle.

Mac et liberté

D’abord, je dois préciser que je n’ai eu que deux MacBook Pro dans ma vie. Et que je n’ai jamais idéalisé cette machine. Elle est pratique et efficace pour mon boulot, point.
J’ai toujours été méfiant par rapport à Apple et à ses logiciels. Pour être plus précis, j’ai toujours refusé d’avoir des fichiers dans un format supporté uniquement sur MacOS. Par exemple, je n’ai donc jamais utilisé la suite bureautique d’Apple. J’ai toujours préféré utiliser LibreOffice, même s’il est de moins bonne qualité. Ma liberté est plus importante que ma productivité.

mardi 9 février 2016

Gérer les droits d'accès des administrateurs WildFly avec un annuaire LDAP

Dans mon billet précédent, j'ai montré comment stocker les données d'authentification des administrateurs WildFly dans un annuaire LDAP. La solution n'était pas complète car on ne gérais pas les autorisations.

Pour ça, il faut activer le mode RBAC et affecter les rôles d'administration aux utilisateurs enregistrés. Pour le billet, on se contentera de deux rôles : celui d'Administrator qui a un accès en écriture à toutes les informations et celui de Monitor qui n'a accès qu'en lecture et qui ne peut pas voir les informations sensibles. On commence par les rôles et on activera le RBAC quand tout sera en place.