DerekSagan a écrit 613 commentaires

le surcout d'XA est negligeable

Tu comptes le surcoût de temps de réponse lors de l'exécution du traitement, et juste ce surcoût là j'imagine.
Non parce qu'il y a le surcoût de complexité, de maintenabilité (pas seulement de l'appli mais aussi de toute la stack middleware), etc. et ceux-là ne sont pas négligeables. Ou du moins ils ne le sont pas dès que tu as passé les 8 semaines après la première livraison de ton appli en prod.

De plus envisager d'utiliser XA en batch de façon automagique dans un MDB, c'est faire l'hypothèse que tout le traitement tient dans une transaction. Et en général pour un batch c'est impossible. Sans parler du fait que même quand ça rentre (par miracle) dans les ressources allouables sur la base et ailleurs, c'est une mauvaise idée d'avoir un scope de transaction énorme.

Ça dépend ce que t'appelles faire du batch.

Si c'est avoir des centaines de traitements d'informatique de gestion toutes les nuits avec des points de reprise pour que des exploitants puissent les relancer le matin (voire des pilotes la nuit) avec des consignes d'exploitation simples (j'ose pas écrire en français simplifié mais je le pense, ah bah si tiens je l'ai écrit), bah comment te dire que je me demande bien comment on peut faire ça avec Camel…

Je préfère de loin avoir le bidule JQM que le bidule Camel pour faire des batches, au sens que je viens de donner à batch. Malgré tous les défauts que j'ai cités plus haut.

Et le bouquin que tu cites il est cool à feuilleter, il présente des jolies briques de lego qu'on peut assembler pour faire des applications qui ressemblent à The Incredible Machine: c'est trop cool à regarder, c'est assez cool à construire, faut pas trop avoir à le maintenir plus d'un an et surtout, surtout, faut jamais avoir à l'exploiter quand un grain de sable rentre dans un rouage.

L'article que tu cites dit que l'API ProcessBuilder est moche et pleine de pièges. C'est vrai. Mais elle est utilisable quand on est obligé de lancer un fils en Java. Même si je reconnais préférer le faire en C qu'en Java.

Depuis Java 5 c'est possible avec un thread par fils. Les flux sont pas selectables mais on peut faire des i/o avec timeout dessus alors on s'en sort. D'ailleurs c'est pas on peut mais il faut, pour les raisons cités dans ton article (pour pas se le faire bourrer d'un coup en mémoire à la mort du process) et pour d'autres (pour pas freezer le fils).

Ok un thread par fils c'est beaucoup si tu comptes avoir des centaines ou des milliers de fils mais dans le cas présenté ici (lancer quelques batches en parallèle) je continue à trouver que c'est un moindre mal par rapport à se retrouver avec un batch qui OOM la JVM et et plante les autres batches. Quand c'est pas pire qu'un OOM (parce qu'encore un OOM c'est la roulette russe, t'as de grande chance de pas tomber sur une balle et que l'exception libère masse mémoire ou les autres batches).

Après si les flux étaient selectables ont pourrait mutualiser un fils sur plusieurs processus, ou au moins éviter l'inélégance de faire des read avec timeout alternativement sur out et err. Certes. Ça ne serait pas pour me déplaire.

Perso j'ai fait en Java 4 et en Java 5 (ou 6 je sais plus mais ça n'a pas d'importance de ce point de vue 6 = 5).

Avant Java 5, tu pouvais pas lire les flux avec timeout du coup t'avais le choix entre ne pas lire les flux et prier pour que le fils ne remplisse pas les buffers et ne se freeze pas, ou bien ne pas pouvoir tuer le fils s'il est trop long car tu étais bloqué dans la lecture des flux, ou encore avoir 3 ou 4 threads (je sais plus) juste pour gérer un flux.

Rien n'empêche d'avoir un job JQM qui lance une JVM externe, ce n'est pas l'esprit mais rien ne l'empêche.

Je pense qu'il y a une certaine valeur ajouté à ce qu'un framework de batches java prévoit et organise réellement le cas et ne se contente pas de laisser le développeur forker une JVM s'il en a envie en lui précisant que ce n'est pas l'esprit.

Tu tiens quelques lignes plus pas dans un commentaire à l'apologie de la beauté de Python les propos suivants, ils sont un peu excessifs mais ont le mérite d'assez bien exprimer les limiter de "ce n'est pas l'esprit mais rien ne l'empêche":

c'est peu brut de décoffrage en Java pour par exemple gérer une communication inter process ou gérer un verrou etc. Il faut tout se refaire à la main

L'objet de mon commentaire est bien de parler des "tâches longues et gourmandes".

Je ne discute pas du bien fondé d'avoir un démon pour exécuter les tâches courtes et fréquentes, je trouve ça pertinent pour tous les arguments que tu développe et même probablement pour d'autres encore.

Je discute le fait d'imposer ce mode de fonctionnement aux traitements lourds, car je pense que c'est une hypothèque sur la robustesse. En effet, les traitements lourds, à un moment ou un autre du cycle de vie des applications, explosent (mémoire/gc, nombre de file descriptors, nombre de connexions base de données, etc.) donc je préfère en terme d'exploitation que quand ils explosent ils n'emportent pas leur petits copains avec eux.

Après, c'est possible dans une certaine mesure d'isoler les traitements lourds mis dans la même JVM mais d'une part c'est dur (affecter des JVM d'exec à certains modules applicatifs, dédiés certaines aux traitements légers et d'autres aux traitements lourds, voire limiter à 1 traitement lourd à la fois dans une JVM, dès que t'as des équipes de dev qui ne se parlent pas ou des versions différentes d'une même appli il faut des class loaders différents par batch, etc.) d'autre part ce n'est pas complètement possible (le nombre de file descriptors et le tas java sont globaux, même avec des class loaders différents et des gestionnaires de sécurité). Du coup la seule façon d'être tranquille c'est de dédier une JVM à un traitement lourd et la façon la plus simple de le faire c'est de lancer la JVM à chaque traitement lourd.

Ça n'empêche pas de traiter les petits/moyens traitements très répétitifs autrement, je ne cherche aucunement à dire le contraire.

Bah depuis Java 5 tu peux killer, avoir les 3 flux (in, out, err) séparément et en nio, et poller ou attendre un fils. Si t'arrives pas à faire du reporting d'avancement et du kill avec ça, c'est que t'as pas lu la doc… ;-)

En fait je n'ai pas trouvé une seule fonctionnalité du module subprocess Python qui ne soit supporté par Java 5. Ce qui n'est d'ailleurs pas bien surprenant, Python comme Java offrant grosso modo 100% des possibilités systèmes communes aux différents OS sur lesquels ils tournent, du coup à part ne pas occulter des fonctionnalités (comme le faisait Java < 5) je ne vois pas bien ce qu'ils peuvent proposer.

Surtout juste pour lancer une JVM depuis une autre JVM et savoir où elle en est (on n'est pas en train de parler de faire du calcul parallèle à la MPI/PVM avec, non plus).

une JVM qui lance une JVM heu… Par ailleurs, il est plus facile de manager un thread qu'un process en java

Je suppose que tu veux dire avant java.lang.ProcessBuilder qui a été introduit en Java 5, c'est bien ça ?

Le coût de démarrage a certes réduit, mais il n'est pas négligeable pour autant

Euh…. Tu dis pas ça sérieusement pour un batch ?

$ cat Hello.java
public class Hello {
  public static void main(String[] args) {
    System.out.println("Hello");
  }
}
$ javac Hello.java
$ time java Hello
Hello
real    0m0.137s
user    0m0.062s
sys     0m0.028s
$ java -version
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.8) (fedora-51.1.8.8.fc13-i386)
OpenJDK Client VM (build 14.0-b16, mixed mode)
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i5 CPU       M 560  @ 2.67GHz
stepping        : 5
cpu MHz         : 2667.000
cache size      : 3072 KB
(...)

Oui enfin c'est juste parce que sur mainframe quand on faisait du français on faisait pas du franglais (éditer ça peut vouloir dire imprimer, mais pas modifier, justement).

Je trouve assez discutable techniquement le fait de faire tourner une JVM serveur/démon/serveur d'appli pour y faire tourner des batches lourds alors qu'il est beaucoup plus sûr techniquement de lancer une JVM pour chaque instance de batch lourd (pas de risque d'exploser le tas ou une autre ressource) et que le coût de démarrage d'une JVM en 2013 est juste ridicule (au regard d'un batch de plusieurs secondes ou plusieurs heures).

Sans parler de la souplesse que peut donner au développeur le fait d'être seul dans sa JVM (un commentateur parlait de SpringBatch plus haut, faire un batch avec SpringBatch dans une JVM dédiée c'est facile, ne pas se marcher sur les pieds quand plusieurs sont dans la JVM il faut réfléchir et se parler entre développeurs voire équipes).

Sinon bravo c'est super intéressant de gérer ce parent pauvre du monde Java qu'est le batch !

Mais vous n'y pensez-pas ? Le clavier c'est hasbeen, il faut leur apprendre à utiliser un écran tactile !

Et de moins chiant à proxifiant (ftp passif, ftp actif, toussa)

Les autres ne sont pas assez ambitieux.
Il faut pouvoir présenter en NNTP une mailbox SMTP ou en SFTP un serveur FTP ou HTTP, sinon c'est pas un reverse proxy c'est un jouet.
http://delegate.org/delegate/

(oui bon je trolle un peu c'est vrai)

arrêter de penser qu'on vie tous à Paris où il est plus simple d'avoir un boulot dans l'informatique

Tu veux dire que là, tu postes ton commentaire depuis ailleurs que Paris ?
Et t'as Internet là-bas ?
En France ? (parce que la Californie ça compte pas, même si c'est pas Paris)
T'as piraté un câble sous-marin ?
Non en fait j'y crois pas. Si tu nous postes pas un twitpic pour prouver que c'est vrai je pense que ton commentaire est un fake.

J'ai pris le boulot qu'on voulait bien me donner, à 500 km de chez moi

Et sinon, pourquoi tu viens pas à Paris au fait, puisque c'est plus simple d'avoir un boulot ?
Plutôt que de faire 500 km (elle est grande ta province, pour faire 500 bornes sans passer par Paris).

Perso j'ai rien contre les végétariens, et je n'ai qu'un seul argument pour le fait de manger des animaux, tu vas être déçu il n'est pas dans ton loto:

J'aime le goût de la viande et je compte bien continuer à en manger.

(mais accessoirement pas à tous les repas ni même tous les jours, c'est pas nécessaire ni même bon biologiquement, et j'aime bien aussi les autres aliments)

Merci à l'équipe de modération, c'était effectivement pénible à lire.

Mouaih, le lien que tu pointes (et beaucoup de règles de style du même genre) tiens plus du grammar nazi ou de l'opinion subjective que de la vraie bonne pratique de programmation objective.

Tiens d'ailleurs à deux pages de la tienne il est aussi dit qu'il ne faut jamais avoir plus de 2 "return" dans la même fonction. C'est rigolo aussi.

Eh non, car induire d'erreur c'est pas français.
:-p

C'est rigolo, mais bon c'est quand même très connu, et tous les IDE qui se respectent (y compris vim) font la coloration syntaxique en conséquence.

En plus compiler avec -Wall c'est pas hyper original non plus, voire c'est une très bonne pratique, au besoin assorti de quelques -Wno-xxx si le code a des spécificités qui rendent -Wall illisible, mais sans -Wno-comment dont je ne vois vraiment pas à quoi elle peut servir à part à rendre cette mésaventure possible.

Tu peux essayer #\ dans un makefile aussi, ça fait pareil (et les IDE le savent aussi).

Bref, c'est pas un commentaire qui influe sur le code, c'est une subtilité des priorités des tokens dans la syntaxe C, qui attire des ennuis au néophyte mal outillé.

Accessoirement appeler "commentaire" un gros ascii-art utilisant des backslash en fin de ligne reste quand même un peu osé. En tout cas c'est sûr que c'est pas un commentaire à visée documentaire.

Oui, je sais, le sujet du commentaire est de la provoc.

Mais qui n'a jamais eu à modifier un code de 10 ans dans lequel les commentaires sont trompeurs car une partie des gens qui ont modifié le code n'ont modifié que le code et pas les commentaires ?

Oui, alors qu'elle aurait été tout aussi compréhensible s'il l'avait commentée, par exemple:

grep -c pat file # compter le nombre d'occurrences de pat dans file

(désolé, pas pu résister)

Peut-être était-ce du second degré. C'est plausible, non ?

À ton service.
La réponse est ici: http://lmgtfy.com/?q=bronsoniser
De rien.

et c'est pas sain pour un croyant…

Kibana, qui me semble plus orienté tableau de bord que requêtage précis

Comme le tableau de bord est filtrable par une requête, tu tape un numéro de transaction ou n'importe quel identifiant présent dans les logs et hop t'as le joli tableau avec les camemberts et les histogrammes mais filtré avec cet identifiant, ainsi que la liste des traces correspondantes. Et dans les traces en question t'as juste à cliquer sur tel ou tel champs pour restreindre la recherche sur un critère supplémentaire.

Des outils pas fait pour requêter précisément comme ça, j'en veux bien quelques uns ;-)