djano a écrit 1147 commentaires

J'adooooore OpenStreetMap!
Bien joue les gars ;)

Peut etre parce que Red Hat fait ses gros sous sur les serveurs ?

Oui, mais RHEL est une version "hardened" de Fedora, avec une QA plus poussee (plus de moyens?) et puis surtout un long support (payant bien sur, mais c'est le jeu ma pauvre Lucette!)

"Liste visuelle des changements" => http://changelog.linfiniti.com/qgis/version/21/

Ça va vite même sans être la NSA…
Oui ce fut le cas pour nous avec un modele de donnees comme suivant ou l'on a un pipe line qui contient de plus en plus de donnees (chaque D represente le volume de donnees):

D => DD => DDD => DDDD => DDDDD
1 => 1000 -> 10000 -> 100000

sachant que la premiere etape (geree par JMS) les volumes etaient aussi en train d'exploser, et il a fallu commencer a dedupliquer les donnees en entree.
Le modele etait ainsi fait que plus l'on avancait dans le pipeline et plus les donnees etaient volumineuses et complexes a gerer avec des regles metiers parfois completement opposees selon le type de donnees.
Hyper interessant, mais pas top quand tes collegues ne sont pas au niveau du challenge :(

dès que tu as plusieurs centaines de milliers de lignes à insérer ou mettre à jour, tu vas avoir très très envie de gérer des commits intermédiaires pour des raisons de perf. Et donc de te passer de la gestion des transactions des middlewares pour gérer tes points de reprise. C'est donc à adapter en fonction de chaque type de batch et de sa volumétrie.

Le probleme etait:

1. l'architecture pas adaptee au volume de donnees
2. la difficulte a casser les sacro saintes transactions en devant convaincre l'humain (en particulier lorsque les requirements faisaient que ca ne tiendrait plus jamais dans une seule transaction) 1.1. les analystes metiers 1.1. les clients

Les analaystes metiers etaient de maniere suprenante les plus difficiles a convaincre. Il y a aussi eu un testeur qui faisait des tests automatiques qui n'a pas aime le changement, mais j'ai du le rembarrer en lui disant que l'on n'avait pas le choix. Le pauvre gars avait pousse sa gueulante a un tres mauvais moment.

Bref assez stressant quand un P1 nous tombait sur le coin de la gueule toutes les semaines.

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.

Tout a fait.

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.

Oui, oui, mais puisqu'il faut tester toute la stack de toute maniere…

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.

Ca commence souvent en parvenant a tenir dans une seule transaction, puis au cours du temps, les volumes augmentent, les requirements changent et/ou s'amoncellent finissant par provoquer des incidents de production P1 dans des cas patologiques. Il faut alors changer l'architecture du logiciel sur cette partie.
Je suis d'accord qu'avoir une scope de transaction enorme est une mauvaise idee en theorie, mais en pratique si ton appli fait 15000 choses (progiciel metier bien complexe) et que tu n'a pas le temps d'etudier la facon dont elle est utilisee, et bien tu pares au plus presse et tu fait le pompier de temps en temps. Bref je suis d'accord en theorie, mais selon l'environnement dans lequel tu travailles et selon les contraintes que tu as, ca n'est pas faisable en pratique.

 

Mais je trouve la discussion interessante. Merci beaucoup.

Dans les faits, c'est une galère pas possible à mettre en marche et de plus c'est horriblement lent.
Comme dit dans un commentaire ci-dessous, le mettre en marche, c'est juste un case a cocher avec WebLogic ou WebSphere. Je ne sais pas pour JBoss.
Oui il y a un surcout a l'execution et c'est une des raisons pour lesquelles certains abandonnent XA pour revenir a l'architecture que tu decris ci-dessous.

Il est préférable de gérer deux transactions séparés, manuellement (bean managed) et de gérer au niveau applicatif le cas d'un crash entre les deux commits (c'est à dire un doublon si les commits sont dans le bon ordre).

Oui si tu as beaucoup de temps a passer pour gerer absolument tous les cas d'erreurs de ton application de maniere propre.
Bon dans les entreprises qui ont aussi d'autres choses a faire, on fait du XA et il n'y a pas de code supplementaire a ecrire, et ca marche tres bien. Il y a une perte de perf mais si ton appli passe son temps a rappatrier des donnees de la Bd, le surcout d'X est negligeable.

SprintBatch est compatible EE… cela veut dire deux framework de dév pour les développeurs.

C'est pas la mer a boire quand tu geres 30 librairies "tirees" depuis maven central.

Et quid d'un morceau de code qui est utilisé à la fois en batch et en interactif ? C'est un peu mélanger l'eau et le feu.

Ca, ca peut etre un probleme en effet. Mais toute appli un peu complexe va avoir du batch est de l'interactif.
Si je me souviens bien, la ou Spring Batch n'etait pas tres bon c'etait pour demarrer un batch paramétré de maniere interactive.

 

En tout cas merci de tes reponses, c'est interessant car ca donne a reflechir.

Quant à la gestion des transactions avec les MDBs… ok, pas de troll.

Dommage c'etait la question qui m'interessait le plus et est absolumment necessaire dans un contexte JavaEE :)

Par ailleurs, Spring Batch est tout a fait utilisable dans du JavaEE.
Il faut juste lui dedier un thread pool qui peut s'etendre sur tout un cluster (attention au cout des licences/du support tout de meme).

J'espère ne pas avoir suscité trop de frustration.

Ne t'inquietes pas, je survivrai :)
Je comprend le manque de temps. Merci encore de partager ton experience.

L'autre choix majeur, qui simplifie énormément le code et la gestion mémoire, est que les événements doivent être consommés immédiatement, ils ne sont pas mis dans une file d'attente. Je pense que ça simplifiera le debug aussi.

Oh oui! Ca va beaucoup simplifier le debug!

Nous avions une implementation permettant de:

• retarder la consommation des evenements jusqu'a la fin d'une transaction, afin d'eviter de traiter inutilement plusieurs fois les memes evenements survenant lors de la meme transaction
• consommer les evenements de maniere synchrone (comme toi)
• consommer les evenements dans une transaction separee.

 

Ca repondait a pas mal de use case :)
En contrepartie, les evenements retardes etaient une plaie a debugger.

Je commençais à avoir des traces, donc j'ai mis en place un système de log pour hiérarchiser l'information un minimum. Je vais assurément m'en servir pour ça aussi.

Attention a l'explosion de la taille des logs!

Merci de partager ta progression sur le jeu. J'aime bien lire tes comptes rendus.
J'aime aussi la video, bravo pour en etre arrive jusque la!

 

J'ai quelques commentaires sur la depeche.

Comme un commentaire au dessus, je suis un peu frustre par tes interrogations qui ne sont pas suivies de pistes de reflexion. Je comprends bien que la reflexion est en cours, ou meme pas encore bien definie, mais c'est justement le cheminement qui fait la richesses de cette serie de depeches. Si tu exposes tes reflexions en cours (ou meme tes ebauches de reflexion) avant d'exposer le choix realise, tu vas beaucoup faire beaucoup plus reagir/faire reflechir les lecteurs qu'en leur presentant le resultat final. Si tu ne fais pas ca, je me demande pourquoi tu nous expose tes interrogations. A vrai dire c'est un peu frustrant pour moi. Ceci dit, tu fais comme tu veux bien entendu :) Je suis deja content que tu partages ton experience et de voir la progression de ton jeu.

 

Concernant le systeme a evenement, cela me semble un prerequis avec des systemes tres complexes ou tu veux totalement decoupler la mise a jour des donnees et les actions a entreprendre suite a la mise a jour de ces donnees.
Cela se voit aussi bien intra-application (ex: bus d'evenements dans Eclipse) que inter-applications (ex: dbus), voire de maniere distribuee (ex: Enterprise Service Bus). C'est une problematique difficile, mais indispensable pour decoupler du code, autoriser les systemes de plugins riches, ou autoriser des changements rapides sans impact sur le code central a une application. Le bus d'evenements, c'est le pattern observer aux steroides: il est generalise a toute application sans devoir repeter le pattern partout.
En gros, cela permet de centraliser la mise a jour des donnees et de factoriser les notifications liees a ces mises a jour.
Malheureusement, comme signale plus haut, les performances peuvent en patir selon l'implementation. Je pense qu'une implementation correcte et de typer les evenements et de se baser sur un systeme publish/subscribe ou le subscribe s'appuie sur le type de chaque evenement afin de limiter les notifications indesirables et la liste des subsriber a parcourir.
Un autre probleme auquel on se heurte parfois est lies a l'ordre d'execution des listeners: il peut etre desirable de les executer dans un ordre precis afin de mettre a jour une donnee avant qu'elle ne soit lue par un autre listener. La combinatoire explose, mais reste plus simple a gerer qu'en ajoutant l'appel de methode X partout ou la donnee Y peut etre mise a jour. Le principal probleme reste l'ajout d'un ou plusieurs niveau d'indirection dans les appels de methodes qui rendent le debogage plus complique. Ce probleme peut etre reduit par l'utilisation de "traces" dans un mode debug qui permettent de comprendre que l'evenement E a ete concomme par le listener L, qui a en retour leve l'evenement F, etc.

Bref, ce n'est pas tres simple mais bien mieux que l'alternative a mon avis.

Pour finir, le choix entre l'utilisation du polling ou du publish/subscribe n'est pas seulement dans les mains du developpeur: est ce que les donnees doivent etre mises a jour au fil de l'eau (le fameux real time des analystes metiers qui n'a rien a voir avec le real time des programmeurs :) ), ou bien est ce qu'un delai entre la mise a jour des donnees et la repercussion de cette mise a jour est acceptable? Est ce que le systeme est transactionnel? quel est le volume de donnees a traiter? etc.
Imaginez la complexite lorsque le systeme est transactionnel, avec un fort volume de donnees et que les regles metiers sont extrement complexes :)
Bref, bienvenu dans le monde la bancassurance!

… alors d'ici 16h30 ce mercredi 11 il est fort possible que les 100% soit atteints ce qui va pourrait établir un record.

Anéfé a 16h30, le compteur vient tout juste d'afficher 101%!!

Le format est effectivement du simplicité déconcertante.

"Le format est effectivement d'une simplicité déconcertante."

Oui, encore une victime du OOM killer ;)

ancinnement => anciennement

Merci pour ces precisions.

Le principe semble tres similaire a "En Vente Libre" dont l'on a parlé tout récemment sur linuxfr.

Quelle est la différence entre les deux?

Pourquoi avoir créé Libre Shop un concept qui semble proche?

Chris Mason travaille toujours sur Btrfs pour autant que je sache.
C'est Oracle qu'il a quitté en 2012 pour travailler chez Fusion-io.

Merci de vos precisions de connaisseurs ;)

Au passage, il parait qu'Apple contribue (ou va contribué) au projet LLVM pour la simple raison que son processeur 64 bits de l'iPhone 5S est basé sur ARMv8/Aarch64.

Je me dois de te contredire: Apple contribue a LLVM depuis bien bien longtemps, en fait depuis l'embauche de Chris Lattner en 2005.
Apple a d'ailleurs lance le projet clang a l'a libere en 2007 d'apres Wikipedia en anglais.

Je n'y avais pas pense a celle la.
J'aime pas bien les knowledge base cachées comme ca, mais je suppose que RedHat doit faire son blé aussi.
Merci de ta réponse.

C'est ce que je m'etais dit.
Merci d'avoir confirme.

Je parlais de la version du systeme de base: la version de GCC qui est utilisee pour compiler le systeme de base.

Je n'ai pas compris ce que couvre le self-support?
On dirait juste que tu te demerdes avec le moindre probleme que tu as.
Dans ce cas, pourquoi payer? Est ce que ca ne couvre que les mises a jours?

Since audio code is mp safe, establish isa(4) and pci(4) audio interrupts with the IPL_MPSAFE flag, so interrupt handlers don't need to wait for global kernel_lock.

Donc il y a visiblement un moyen de synchronisation plus fin que le verrou global du noyau.

Merci d'avoir lu le changelog pour moi! Doh! :(

C'est une excellente nouvelle pour OpenBSD qui est un projet dont j'apprecie beaucoup l'approche d'ingenierie logicielle.

il me semble que Theo de Raadt refusait l'abandon du Giant Lock car cela rendrait le code moins sur et plus difficile a auditer

{{référence nécessaire}}

Je n'ai pas trouve de references. J'ai cherche partout, mais beaucoup d'interviews de Theo de Raadt ont disparu dans les limbes de l'internet.

Ou bien je l'ai reve, ou bien j'ai mal compris une interview, je ne sais plus. Je ne trouve plus de traces a ce sujet.

Je pensais vraiment que tous les BSDs avaient refuse cette licence.
Il semble tout de meme que la migration de tous les BSD vers Clang est en route.

Pour autant que je sache, OpeBSD et les autres BSD utilisent un GCC pre GPLv3.
Donc toute les nouveautes post GCC 4.2.1 ne seront dans aucun BSD.
Les BSD vont progressivement migrer vers Clang. D'ailleurs, FreeBSD utilisera Clang par defaut pour sa prochaine version majeure.

http://gcc.gnu.org/ml/gcc-announce/2007/msg00003.html

GCC 4.2.1 will be the last release of GCC covered by version 2 of the
GNU General Public License. All future releases will be released
under GPL version 3.

http://www.openbsd.org/cgi-bin/man.cgi?query=gcc-local&sektion=1

OpenBSD uses derivatives of gcc(1) versions 3.3.6 or 4.2.1,