Donc je n’arrive pas a joindre cette adresse http://localhost:9200/g1-test/block/current
mais dans les logs j’ai vu cette ligne :
j’ai donc essayé avec mon adresse ip : ws://163.172.178.252:9402/ et j’obtiens ça :
Donc je n’arrive pas a joindre cette adresse http://localhost:9200/g1-test/block/current
mais dans les logs j’ai vu cette ligne :
j’ai donc essayé avec mon adresse ip : ws://163.172.178.252:9402/ et j’obtiens ça :
Cette ligne indique que le serveur de websocket et lancé sur la port 9402 (pour info, joignable uniquement si tu met ws://163.172.178.252:9402/ws/<chemin_valide>
sinon ca réponds pas).
Mais un autre serveur (HTTP cette fois) a du être lancé (plus haut dans les logs) sur 9200 (ou 920* en fonction des ports déjà occupés).
Sur cette machine, comment fais tu pour accéder aux autres service (duniter, etc), depuis chez toi ? As tu un reverse proxy nginx, ou ouverture de port directe sur les port locaux ?
Yes !
Nouvelle version : duniter4j-es-0.17.1.
Plusieurs anomalies remontées lors des 1er tests y sont corrigés.
@elois, a priori le problème de JDK n’a rien à voir avec ton soucis.
ES_USER_API
et ES_SUBSCRIPTION_API
dans leurs endpoints.
etc.
N’hésitez pas à commenter/questionner cette solution.
Nouvelle étape importante pour Cesium+ : un 2ème noeud ES vient de débuter sa vie ! Les 2 noeuds discutent bien entre eux : jusqu’ici l’entente est cordiale !
Ce 2ème noeud, fonctionne de manière complètement autonome de g1.duniter.fr
, sur un autre serveur :
note : j’ai désactivé (par configuration) la découverte dynamique de nouveaux noeuds ES, pour reste “en famille” pour le moment. Mais rien n’empêche d’ajouter vos noeuds, branchés sur les miens.
Bref, enfin un déjà début de décentralisation de mes travaux ! ^^
J’espère que d’autres pourront me rejoindre ? @elois ? @vincentux ?
Et pourquoi pas @cgeek et @Florck sur duniter.org ? (…mais peut-etre faut-il attendre un peu avant)
ok je retesterai avec ma JVM Oracle dés que je peut, si c’est pas demain soir ce sera le soir d’après
Grâce à une nuit de synchronisation entre les noeuds ES, j’ai détecté un bug majeur dans Cesium+ (bug non détecté par les noeuds ES): le timestamp des documents Json (messages, profiles, etc.), c’est à dire la propriété time
, n’était pas toujours incrémenté par Cesium.
Or ce champ permet des synnchronisations différentielles entre noeuds, par comparaison des “versions” du document (pour déterminer le plus récent).
j’ai donc du :
time
;time > previous_time
Vous allez surement me dire : “mais comment tu peux utiliser une heure, si elle est donné par le client ? elle n’est pasdigne de confiance !”. La solution mise en oeuvre est simple :
time
, dans des documents reçus;time
: sont ignoré les documents déjà à jour ou plus anciens.En effet, je n’utilise pas l’heure blockchain, à cause du problème des rollbacks qui risquerait de rendre invalide des documents de l’utilisateur.
Bref, l’heure indiqué dans les documents n’est pas “exact” mais bien celle fournie par le client, mais on s’en fiche car ces données ne sont peu critiques
N’hésitez pas à me faire des remarques/critiques.
EDIT: mieux vaut donc ne pas utiliser encore le noeud ES g1.data.le-sou.org. Je vais devoir le resynchroniser complètement
Oui tout à fait !
C’est pas plutôt un décalage minimal ? Dans le sens où le nœud Cesium+ refuse un document qui serait signé à un intervalle trop court par exemple.
Oui bien. Je rajouterai “le nœud Cesium+ refuse tout document dont la date/heure UTC+0 est supérieure à l’horloge locale UTC+0, avec acceptation d’une marge d’erreur de 10 minutes (par exemple)”.
Pour éviter le spam, c’est ca ? Par exemple mise à jour trop rapide d’un même doc ?
Je n’y avais pas pensé, mais pourquoi pas oui.
Non, je parlais d’une erreur maximale autorisée dans l’heure. Par exemple, si le noeud est à 12h00 (UTC+0) alors il acceptes les documents avec un time compris entre 11h50 et 12h10 (UTC+0).
Cela dis, à cause des problèmes d’horloge, je penses qu’on peut même accepter +/- 1 heure, non ?
non, pas dans le cas d’une synchronisation depuis un autre noeud ES, car il peut très bien à avoir une coupure réseau longue. A moins que tu voulais parler de la synchro directe, par WebSocket ? Pour celle-ci oui, je pourrais ajouter le contrôle de time.
En résumé :
Oui. Enfin ça ne te gêne peut-être pas plus que cela pour les nœuds Cesium+.
Une coupure réseau même de quelques jours n’implique pas un décalage horaire de plusieurs minutes ! C’est important de refuser les documents écrits dans le futur par rapport à l’heure indiquée par ton nœud, sinon c’est la porte ouverte à une attaque de spam.
A oui effectivement pour les dates dans le futur on peut les refuser. C’est seulement pour les dates du passé qu’on ne peut pas, sans risquer de perdre une partie des données. Pour ce cas là, il faudra peut-etre passer par un quota / utilisateur, je ne sais pas…
@florck question ES : quelle est la bonne pratique pour lancer 2 noeuds ES sur la meme machine :
bin
, config
, data
etc.) et donc avoir 2 fichier de configuration/bin/./elasticsearch -d
?Merci de ton aide
Hello @kimamila
Alors en fait, lancer 2 noeuds ES n’est pas “bonne pratique”
Mais si tu as une bonne raison de le faire (par exemple ton serveur à plus de 32G de RAM) dans ce cas, il faut faire 2 installations complètement distinctes, le mieux serait alors de containeriser (docker / lxc) pour permettre une bonne séparation des ressources.
En fait, j’avais pensé faire cela pour les mises à jour sans interruption de service… en ayant besoin d’une seule machine. (et par failover nginx)
Tu vois le truc ? Comment t’y prendrais tu @florck ?
en fait pour ça effectivement ce serait d’avoir un cluster multi-node et donc sur des machines différentes de façon préférentielle. Car ce que tu veux est de la HA (high availability).
Sinon pour ton besoin précis, tu peux toujours redémarrer un elasticsearch dans un conteneur sur la même machine alors que le elasticsearch de ton host tourne toujours.
Mais c’est un peu usine à gaz…
Bon, je penses que la v0.18.2 de duniter4j est la bonne, niveau synchro P2P !
J’ai 2 noeuds parfaitement synchronisés (en production !) => démo sur https://g1.le-sou.org
Qui peux/veux tester ?
pour l’installation : on dézippe et on lance la commande <HOME>/bin/elasticsearch
. Vous serez directement en prod : toutes les données Cesium+ en redondance parfaite chez vous !
(Pour que le noeud ES soit visible dans la vue réseau Cesium, il faudra ensuite ajouter des endpoints.)
EDIT: @elois, si pas ou peu d’inscriptions pour l’atelier de dev Cesium+, reste il de la place dans les jours techniques pour présenter cela. C’est à dire présentation des évolutions techniques Duniter4j/Cesium+, et démo de la synchro P2P ?
J’ai tenté l’installation, je suis tombé là-dessus :
./bin/elasticsearch
Exception in thread "main" java.lang.IllegalStateException: duniter4j-es-core requires Java 1.8:, your system: 1.7
J’ai donc installé openjdk-8-jre, mais j’ai toujours le même message.
Ça demande certainement plus d’investigations, mais je n’ai pas trop de temps devant moi dans l’immédiat.
Oui il y a toujours le créneau de jeudi de 16h à 17h
Tu peux forcer la JVM à utiliser, via la variable d’environnement JAVA_HOME
, en l’exportant, avant de lancer ./elasticsearch
Va pour ca alors !