C'est la mission que s'est donnée Terracotta avec son outil OpenTerracotta. L'idée derrière le concept de Terracotta est de descendre la mise en grappe d'un cran pour l'appliquer directement aux machines virtuelles Java. Ceci permet de faire fonctionner une application trop gourmande pour une seule JVM sur plusieurs d'entre-elles de façon complètement transparente pour l'applicatif. De cette manière, le développeur est débarrassé de toute préoccupation de programmation en grappe et peut ainsi se consacrer pleinement à son application dont la conception est de fait simplifiée.
L'architecture d'une telle solution est classique quand il s'agit de clustering : un serveur, des clients et (moins courant) un serveur de stockage.
Les clients accueillent chacun une JVM qui inclut au démarrage un ensemble d'API Terracotta. Leur rôle est d'intercepter les appels Java responsables de la synchronisation des processus est d'y injecter du bytecode afin d'informer le serveur Terracotta des changements effectués sur le tas (heap) et donc les altérations subies par les objets. Les composants Terracotta répartis ne s'échangent que des deltas sur les objets des tas et économise ainsi la bande passante. Toutes les données qui concernent les objets Java sont enfin conservées par le serveur de stockage.
Dans les faits, Terracotta trouve quatre champs d'applications majeurs :
- Réplication de sessions HTTP (Tomcat, Oracle WebLogic, Struts, Spring, ...)
- Cache Distribué
- Clustering de POJO/Intégration Spring
- Collaboration, Coordination, et gestion d'évènements
# KISS
Posté par Pierre . Évalué à 10.
Bon je retourne a mon noyau...
[^] # Re: KISS
Posté par thedidouille . Évalué à -1.
Ce qui est un gros plus en terme de simplicité. En terme de performance aussi.
[^] # Re: KISS
Posté par qstone . Évalué à 7.
On ne devient pas Pierre Tramo en 1 jour !
[^] # Re: KISS
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 3.
Encore un vilain tour d'IPoT…
# Ca me fait doucement rire ....
Posté par totof2000 . Évalué à 2.
Dire qu'on pourrait se passer de clustering en n'utilisant pas des usines à gaz tel que JavaEE (en utilisant pas java tout court d'ailleurs).
Celui-ci vise à augmenter les ressources allouées aux applications en multipliant les serveurs à sa disposition.
Alors ..... 1 serveur Quadri Pro Quatre coeur juste pour Jave, deux autres serveurs identiques JavaEE, quatre serveur pour gérer le clustering et 1/2 serveur pour l'appli. Cool !!!
De cette manière, le développeur est débarrassé de toute préoccupation de programmation en grappe et peut ainsi se consacrer pleinement à son application dont la conception est de fait simplifiée. Génial, le développeur, débarassé de ces basses questions matérielles pourra développer sans optimisation. On s'en fiche, si ça tient pas la charge, on ajoute un serveur pour absorber tout ça. On pourra donc passer via une archi multicouche, avec communication XML entre les couches qui feront appel à d'autres couches pour le parsing .....
Je me marre ....
[^] # Re: Ca me fait doucement rire ....
Posté par timid . Évalué à 0.
[^] # Re: Ca me fait doucement rire ....
Posté par totof2000 . Évalué à 2.
[^] # Re: Ca me fait doucement rire ....
Posté par totof2000 . Évalué à 2.
Faiut rajouter 5 serveurs pour gérer la grappe !!! Et on parle d'économies d'énergie ? Et ces trucs sont censés simplifier la vie ?
[^] # Re: Ca me fait doucement rire ....
Posté par Olorim . Évalué à 4.
Bon, je plaisante bien sur, mais la réalité, c'est que développer en entreprise, c'est faire de la merde très vite, et de préférence avec une belle interface utilisateur. Que ça nécessite un supercalculateur derrière, c'est le problème du client...Qui voit la virtualisation comme décrit ci-dessus...
Ce que j'adore, c'est quand les projet débarquent en nous disant que UNIX, c'est de la merde parce que leur application elle crash toute les semaines...
Enfin bon, java c'est beau, c'est facile et ça peu rapporter gros...(Sic!)
[^] # Re: Ca me fait doucement rire ....
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
http://jean-pierre-troll.blogspot.com/2009/06/les-machines-v(...)
[^] # Re: Ca me fait doucement rire ....
Posté par Olorim . Évalué à 2.
[^] # Re: Ca me fait doucement rire ....
Posté par bubar🦥 (site web personnel) . Évalué à 7.
Devrait on obligé les développeurs Java à commencer par de l'embarqué afin de "bien apprendre le langage et ses finesses ?" J'en sais rien, mais ça me titille pour moi en tout cas.
[^] # Re: Ca me fait doucement rire ....
Posté par Olivier Serve (site web personnel) . Évalué à -2.
[^] # Re: Ca me fait doucement rire ....
Posté par thedidouille . Évalué à 3.
Va utiliser Zend et prie. Amen.
[^] # Re: Ca me fait doucement rire ....
Posté par galactikboulay . Évalué à 1.
[^] # Re: Ca me fait doucement rire ....
Posté par Olorim . Évalué à -1.
[^] # Re: Ca me fait doucement rire ....
Posté par thedidouille . Évalué à 7.
Terracotta, c'est :
- pas de SQL (donc pas de DB),
- du lazyloading,
- de la redondance au cas où ...
Je vois pas comment on peut dire que c'est de la merde. En plus, contrairement à Hibernate (très lourd), il utilise du Bytecode enhancement, qui consiste à compiler le code de synchronisation à l'execution (comme Toplink, la couche JPA d'Oracle).
Donc tu ne peux pas avoir PLUS SIMPLE et PLUS PERFORMANT, si tu comprends un minimum comment ça marche. Ou alors, montre moi qu'il peut y avoir mieux en gardant la même simplicité ...
Je sais qu'il y en a beaucoup qui ne jure que par le php, j'ai été grossier et m'en excuse, mais si vous commencez à venir cracher sur java, faudrait juste un peu d'arguments (si possible, non affectif).
[^] # Re: Ca me fait doucement rire ....
Posté par ckyl . Évalué à 10.
Ebay c'est du Java (Ils utilisent que la partie "basse" de J2EE), Amazon c'est majoritairement du Java (Certains traitement sont en C++ ou Perl), linked-in c'est du Java (sauf la gestion du graphe), certains service yahoo c'est du java, orbitz aussi. Non vraiment y'a rien a dire Java ca marchera jamais, c'est pas efficace et y'a pas plus couteux en prod. Tout les gros s'en sont d'ailleurs aperçu, et ne contribuent absolument pas aux projets de la fondation Apache ;-)
C'est pas par ce que les SSII pondent des bouzes infâmes que Java c'est de la merde. C'est juste par ce qu'ils pondent des bouzes...
[^] # Re: Ca me fait doucement rire ....
Posté par Boa Treize (site web personnel) . Évalué à 5.
[^] # Re: Ca me fait doucement rire ....
Posté par claudex . Évalué à 8.
Je proteste énergiquement, il n'y pas d'heure pour faire ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Ca me fait doucement rire ....
Posté par zebra3 . Évalué à 7.
Quand on voit des sites comme Voyages-SNCF, oui, on se met à douter des compétences des équipes engineering, quelle que soit la taille du site, et pas forcément à tord.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ca me fait doucement rire ....
Posté par Antoine . Évalué à 4.
[^] # Re: Ca me fait doucement rire ....
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
Attends, je rêve ou tu es en train de nous citer comme exemple le site de la SNCF ?
Excusez-moi un instant, je reviens… (ha ha ha ha ha ha HA HA HA HA HA HA HA HA HA HA HA HA HA HAaaaaaaarrrrhh de l'air, aïe, mes côtes…). Pfiou, ça va mieux.
C'était ironique, n'est-ce pas, cette citation de la SNCF ?
[^] # Re: Ca me fait doucement rire ....
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
http://linuxfr.org/~ploum/27723.html
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ca me fait doucement rire ....
Posté par thedude . Évalué à 4.
- JAVA (le langage) -> annotations/génération automatique
gne?
T'as compris le concept des annotations au moins ou bien?
- .java -> .class -> .jar -> .war -> .ear
Pareil, gne?
class = java compile.
jar = zip (contenant des .class et ce que tu veux en fait). On pourrait tout mettre dans un class, mais heu ca va etre vilain quand meme et pas tres tres pratique.
war = zip
ear = zip
- JPA/spring ce sont apparement des problèmes. Révolution : on peut ne pas les utiliser.
mettre jpa et spring dans la meme phrase, c'est pour le moins etonnant.
Moi je veux bien me passer de jpa, maintenant tout le monde stocke ses donnees dans une base de donnees relationnelle.
Si tu connais un meilleur moyen d'interfacer du code avec un sgbdr sans devenir completement chevre a ecrire des requetes sql de partout pour persister un graphe de quelques dizaines d'objets de types completement differents, en mettant les trucs dans l'ordre pour les foreigns key, faire tes delete on cascade et tout le tralala, je suis toute ouie et je t'ecoute avec grande attention.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ca me fait doucement rire ....
Posté par thedude . Évalué à 2.
aaaaaah.
C'est ptetre stupide, mais c'est encore ce qui marche le mieux, vois tu? J'ai meme envie de dire que c'est le seul truc qui marche...
Ca te gène pas 3 zip l'un dans l'autre ? C'est vraiment une solution batarde, des couches inutiles l'une au dessus de l'autre (Tu ne vois vraiment pas plus simple ou tu es vraiment de mauvaise foi ?).
Franchement, si c'est le seul "reproche" que t'as a afaire sur la complexite de java, t'es passe a cote d'un paquet de trucs.
hint: ton war ou ton ear peut contenir que des fichiers, et aucun autre zip.
C'est juste crade de balancer tes .class, si tu veux virer une lib, tu vas etre marron.
Un question pour toi, quand tu met une lib dans /usr/lib, tu met un .so? ou tu met tous les petits fichier .o a la queu leu leu?
Quand tu zippes un repertoire, tu prends soin avant de dezipper chaque archive que t'aurais dedans?
Si grouper des fichiers qui vont ensemble est inutile, je sais pas quoi te dire.
Bien sur, c'est un bidule qui a été ajouté pour pallier à des trucs (méta-informations, macros, dynamisme - certaines formes -, ...
Macros?!?!!!?
Les annotations sont des meta infos, c'est tout, ni plus ni moins. C'est des donnees statiques, pas de code, juste des donnees. Une annotation ne fait en rien en soi, c'est soit le compilo, soit le code appelant qui va les verifier..
C'est quoi la difference entre un #pragma override et un @Override?
Comment tu m'implementes un @Required avec des macros et des pragmas?
Quelles annotations peuvent etre remplacee par des macros?
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Ca me fait doucement rire ....
Posté par thedude . Évalué à 1.
Et comment ton code appelant fait pour savoir que ton attribut est required?
Tu la met ou ton annotation? Non pas la, non...
'fin je sais pas, tu serais venu me dire "les generics sont a chier, c'est une implementation ni faite ni a faire parce que sun a pas eu les couilles de casser la compat", j'aurais compris et abonde dans ton sens, qualifier les annotation d'un truc lourd qui est une surcouche inutile a une tare, la je comprends pas, ton message ne veut rien dire...
[^] # Re: Ca me fait doucement rire ....
Posté par thedude . Évalué à 0.
Explique moi donc comment tu implementes une quelconque annotation runtime avec des #define et des #pragma.
La tu parles visiblement de c/c++/objc, donc je suis tres tres curieux de savoir comment tu vas implementer ca.
Quand au etc. je voudrais bien savoir a quoi il correspond.
Je pense que tu ne connais pas les macro common lisp
Non, je ne connais pas lisp, donc expliques moi.
[^] # Re: Ca me fait doucement rire ....
Posté par lasher . Évalué à 3.
(Sinon LISP c'est bien pour de vrai)
[^] # Re: Ca me fait doucement rire ....
Posté par ckyl . Évalué à 6.
Facebook utilise différents langages et fonction des besoins, et essai d'utiliser le plus adapté au service. Tu retrouves, entre autre, du:
- PHP pour les frontend
- Du C/C++ pour les caches, pour les serveurs de photos (cf. http://www.facebook.com/note.php?note_id=76191543919 ) ou pour la gestion des logs (voir scribe)
- Du Java pour tout ce qui touche au datawarehouse: Grosse contribution à hadoop, pig et hive, cassandra pour du map/reduce, bigtable & co
- De l'Erlang pour le service de Chat
- Du Python (voir tornado)
D'ailleurs c'est pas un hasard si facebook à créé thrift qui permet la serialization et les appels RPC entre plusieurs langages !
Et certainement beaucoup d'autres choses qu'ils n'ont pas documentés.
Et pour le bozo qui t'as répondu, fourni un service qui tient la charge de fb et on en reparle après. Pour rappel, il y a quelques temps c'était 550.000 photos/sec servies en pic, 220 millions de nouvelles photos/semaine, 400 milliards de pages/mois.
[^] # Re: Ca me fait doucement rire ....
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Et tu proposes quoi à la place?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ca me fait doucement rire ....
Posté par yellowiscool . Évalué à 6.
Envoyé depuis mon lapin.
[^] # Re: Ca me fait doucement rire ....
Posté par totof2000 . Évalué à 4.
# Halala Java
Posté par crotte . Évalué à 4.
Il y à 7 ans, je n'aimais pas Java, j'étais un "webmasteur qui maîtrise le Php" et Java c'était naze. Ensuite, chose que semble t'il personne ici ne fait, pour pouvoir critiquer je me suis décidé à apprendre Java.
Java est plus gourmand que Php oui. Je code en Java avec Eclipse qui prend beaucoup de ressources alors que je fais du Php avec n'importe quel éditeur de texte. Mais Java est complexe et permet de tout faire, notamment grâce aux innombrables API[2], contrairement à Php.
La complexité rebute sûrement les faibles capacités intellectuelles de certaines personnes qui, dans l'incapacité de comprendre ce langage, préfèrent le critiquer.
[1] Dont le formulaire d'inscription et les restrictions sur le login sont en complète opposition avec les bonnes pratiques que beaucoup ici font semblant de défendre.
[2] Les APIs sont la preuve d'un langage bien pensé. Essayez de trouver une API en Php et cherchez sont équivalent en Java, vous aurez certainement un ratio de 1:3. Après il reste à étudier les trois possibilités et voir laquelle correspond el mieux à vos attentes, à moins que devoir choisir et risquer de faire un mauvais choix vous fasse peur.
[^] # Re: Halala Java
Posté par Duncan Idaho . Évalué à 10.
On rigole de Java, mais on rigole aussi de PHP.
En fait, à part Lisp, rien n'est assez beau pour nous.
[^] # Re: Halala Java
Posté par Dr BG (site web personnel) . Évalué à 4.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Halala Java
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: Halala Java
Posté par zebra3 . Évalué à 3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Halala Java
Posté par nomorepost . Évalué à 10.
J'étais même sûr qu'il y en avait certains réceptifs à l'auto-dérision.
La complexité rebute sûrement les faibles capacités intellectuelles de certaines personnes qui, dans l'incapacité de comprendre ce langage, préfèrent le critiquer.
C'est puissant et argumenté comme raisonnement ca. Ca te place tout de suite intellectuellement au dessus de ceux que tu critiques.
[^] # Re: Halala Java
Posté par Sytoka Modon (site web personnel) . Évalué à -3.
Moi, les packages en org.machin.truc... je pense que le défaut de conception est à la racine.
[^] # Re: Halala Java
Posté par Ontologia (site web personnel) . Évalué à -1.
??
OK je -----> []
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Halala Java
Posté par nomorepost . Évalué à 10.
Moi, les packages en org.machin.truc... je pense que le défaut de conception est à la racine.
Houlala ! Parler de défaut de conception et citer Perl en référence.
Y'en a qui osent quand même !
[^] # Re: Halala Java
Posté par bubar🦥 (site web personnel) . Évalué à 5.
:-)
Un des avantages de Java c'est qu'il n'est pas borné à une finalité. Java c'est aussi de zolis programmes sur des téléphones pas du tout smartphones (et pourtant ça marche). Java c'est aussi des applis dans de petites boites qui se baladent partout, vraiment partout. Bref quant php essaie encore de faire ses pruves sur le web, Java a tout conquis. Donc bon... Objectivement... Ce n'est pas parcequ'il y a des contres exemples que c'est nul. Sinon on pourrait dire que le C c'est super lourd, à la vue de Gnome.
/zut c'est jeudi
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.