Beta-test Duniter4j (ElasticSearch API) 0.16.1 > avec synchronization P2P!

kimamila · 20 September 2017 15:31

Enfin, depuis le temps que j’en parle… voici la 1ère version de Duniter4j ES v0.16.2 capable de synchro P2P.

Pour mémoire, Duniter4j ES sert à stocker les données de Cesium hors blockchain : profils Cesium+, statistiques (pour les graphs, messages privées, etc.
On approche donc (à grand pas) d’une vraie décentralisation de ces données !

Avis donc aux techniciens qui voudraient m’aider à tester.

Installation

ATTENTION: Cette version n’est PAS à utiliser sur Ğ1 pour le moment. Mieux vaut bien tester avant, sur Ğ1-test.

Installez le noeud ES en suivant ces instructions.

Vérifiez bien que vous branchez le noeud ES sur Ğ1-test, c’est à dire sur :

g1-test.duniter.org:10900 pou rle noeud Duniter
et g1-test.data.duniter.fr:443 pour le noeud ES de première synchro

Le noeud ES de production n’est pas encore compatible avec la v0.16.x. (J’attends vos tests pour le faire…)

Tests avancés

Pour bien tester votre installation, le mieux est de brancher un Cesium dessus.

Vous devriez alors voir apparaitre les graphiques sur la page monnaie, les notifications, etc.

Debuggage > activer les logs

Si les graphs ne s’affichent pas (cc @elois), ou un autre problème du genre, voici comment passer les logs en DEBUG :

Editer le fichier <ES_HOME>/config/logging.yml
Modifier la ligne suivante, comme indiqué :

  duniter: DEBUG

de même pour la ligne :

  org.duniter: DEBUG

redémarrez le noeud (kill -15 <PID> ou Ctrl+C fonctionne bien ! )
les logs seront visibles dans <ES_HOME>/logs/<cluster_name>.log

Si cela ne suffit pas, vous pourrez passer les logs en TRACE

kimamila · 20 September 2017 15:53

Pour le moment mon noeud (g1-test.data.duniter.fr) ne récupera pas les modifs faites sur vos noeuds. en revanche l’inverse fonctionnera.

Dès que plusieurs noeuds de tests auront pu etre lancés chez vous, j’activerai les synchros également depuis mon noeud.

elois · 20 September 2017 16:02

Noeud MLO de test installé et lancé (data.g1-test.monnaielibreoccitanie.org:443), mais je ne suis pas sur que la config soit bonne car pour l’instant je n’ai rien, le cesium de test est ici : http://cesium-test.monnaielibreoccitanie.org

kimamila · 21 September 2017 06:00

@elois, effectivement, ton noeud ES n’a pas bien indexé la blockchain (Il manque des blocs… c’est très étrange).

Peux tu s’il te plait :

arreter le noeud ES
supprimer les données, en supprimant le répertoire /data/<cluster_name>
changer ta configuration pour indexer le noeud de @cgeek : g1-test.duniter.org:10900
activer les logs TRACE
lancer le noeuds
attendre quelques minutes, puis m’envoyer les logs en MP

Peux tu aussi me donner :

le résultat de la commande : java -version
m’envoyer ton fichier config/elasticsearch.yml

Merci !

elois · 21 September 2017 13:58

done !

kimamila · 22 September 2017 10:05

Nous n’arrivons pas à démarrer correctement le noeud ES sur le serveur @elois (qui a une JVM Oracle).
Quelqu’un peut il essayer sur un Linux avec un JVM OpenJDK ?

Pour installer, c’est très simple : libsodium+Java 8+ dézipper l’archive ZIP
puis dans /bin lancer ./elasticsearch

merci !

EDIT: @elois si le problème vient de la JVM, je fera une archive avec OpenJDK intégré (bundle)

vincentux · 22 September 2017 18:56

Je viens de lancé le mien pour voir

avec openjdk :

~/duniter4j-es-0.16.1/bin$ ./elasticsearch
[2017-09-22 18:54:28,050][INFO ][node                     ] [Sharon Friedlander] version[2.4.5], pid[5836], build[c849dd1/2017-04-24T16:18:17Z]
[2017-09-22 18:54:28,052][INFO ][node                     ] [Sharon Friedlander] initializing ...
[2017-09-22 18:54:32,665][INFO ][plugins                  ] [Sharon Friedlander] modules [reindex, lang-expression, lang-groovy], plugins [duniter4j-es-user, mapper-attachments, subscription, duniter4j-es-core], sites []
[2017-09-22 18:54:33,161][INFO ][env                      ] [Sharon Friedlander] using [1] data paths, mounts [[/ (/dev/vda)]], net usable_space [40.4gb], net total_space [45.7gb], spins? [possibly], types [ext4]
[2017-09-22 18:54:33,161][INFO ][env                      ] [Sharon Friedlander] heap size [1007.3mb], compressed ordinary object pointers [true]
[2017-09-22 18:54:47,826][INFO ][duniter.security         ] [Sharon Friedlander] Enable security on all duniter4j indices
[2017-09-22 18:54:49,059][INFO ][node                     ] [Sharon Friedlander] initialized
[2017-09-22 18:54:49,059][INFO ][node                     ] [Sharon Friedlander] starting ...
[2017-09-22 18:54:49,376][INFO ][org.duniter.elasticsearch.PluginSettings] [Sharon Friedlander] Starts i18n with locale [fr] at [/home/vincentux/duniter4j-es-0.16.1/data/i18n]
[2017-09-22 18:54:50,025][INFO ][transport                ] [Sharon Friedlander] publish_address {127.0.0.1:9300}, bound_addresses {[::1]:9300}, {127.0.0.1:9300}
[2017-09-22 18:54:50,060][INFO ][discovery                ] [Sharon Friedlander] duniter4j-g-test-vincentux/fmrXQnAkT-Cx9ARYJZZlZQ
[2017-09-22 18:54:53,393][INFO ][cluster.service          ] [Sharon Friedlander] new_master {Sharon Friedlander}{fmrXQnAkT-Cx9ARYJZZlZQ}{127.0.0.1}{127.0.0.1:9300}, reason: zen-disco-join(elected_as_master, [0] joins received)
[2017-09-22 18:54:53,496][INFO ][http                     ] [Sharon Friedlander] publish_address {127.0.0.1:9200}, bound_addresses {[::1]:9200}, {127.0.0.1:9200}
[2017-09-22 18:54:53,497][INFO ][node                     ] [Sharon Friedlander] started
[2017-09-22 18:54:54,189][INFO ][gateway                  ] [Sharon Friedlander] recovered [10] indices into cluster_state
[2017-09-22 18:54:56,824][INFO ][duniter.ws               ] [Sharon Friedlander] Starting Websocket server... {locahost:9400-9410}
sept. 22, 2017 6:54:59 PM org.glassfish.grizzly.http.server.NetworkListener start
INFOS: Started listener bound to [0.0.0.0:9400]
sept. 22, 2017 6:54:59 PM org.glassfish.grizzly.http.server.HttpServer start
INFOS: [HttpServer] Started.
sept. 22, 2017 6:54:59 PM org.glassfish.tyrus.server.Server start
INFOS: WebSocket Registered apps: URLs all start with ws://locahost:9400
sept. 22, 2017 6:54:59 PM org.glassfish.tyrus.server.Server start
INFOS: WebSocket server started.
[2017-09-22 18:54:59,621][INFO ][duniter.ws               ] [Sharon Friedlander] Websocket server started {locahost:9400} on path [/ws]
[2017-09-22 18:55:11,923][WARN ][org.duniter.elasticsearch.user.PluginSettings] [Sharon Friedlander] No keyring in config. salt/password (or keyring) is need to signed user event documents. Will use a generated key [2xgoUQV2oDnRYXamVo3gYZC54gG9Tg9dPWCGXPJHx56K]
[2017-09-22 18:55:11,925][WARN ][org.duniter.elasticsearch.user.PluginSettings] [Sharon Friedlander] No keyring in config. salt/password (or keyring) is need to signed user event documents. Will use a generated key [BwPV6NUsSgCZx3jdEeC5CaJ9XYta6KMamKgieiw6B16k]
[2017-09-22 18:55:23,993][INFO ][duniter.core             ] [Sharon Friedlander] [g1-test] Indexing blockchain...

kimamila · 26 September 2017 09:41

@vincentux tout cela a l’air bon.
Mais est-il allé plus loin ensuite, sur l’indexation de la blockchain ?
Tu devrais voir quelque chose comme :

[2017-09-24 00:17:10,057][INFO ][duniter.core       ] [g1-test] [g1-test.duniter.org:10900] Indexing block #54714 / 55714 (90%)...
[2017-09-24 00:17:10,057][INFO ][duniter.core       ] [g1-test] Indexing blockchain [OK]

vincentux · 26 September 2017 09:51

je l’ai relancé, mais il me semble bloqué a ce niveau…

[2017-09-26 09:43:50,100][INFO ][duniter.core             ] [Ultimus] [g1-test] Indexing blockchain...
[2017-09-26 09:44:00,248][INFO ][duniter.blockchain       ] [Ultimus] [g1-test] [BASIC_MERKLED_API g1-test.duniter.org 10900] Indexing last blocks...

kimamila · 26 September 2017 09:58

Peux-tu activer les log DEBUG (cf 1er post de ce fil), le relancer et me redire ?

vincentux · 26 September 2017 10:24

les logs sont très long j’ai du couper en plusieurs morceau (et encore il n’y a pas tout),
j’espère que tu va t’y retrouver

https://framabin.org/?558c19783f7c4938#qCF5KbQohR4JkKZkSfVedel+lmHimGMBscmmFzzPVxk=

https://framabin.org/?722b84c2017b4a45#RFjynrCrH/mibFYqIV2yR0y0krSOpUhD0/RL8WAhPHs=

ça télécharge pleins de bloc comme celui la :

{
    "version": 10,
    "nonce": 10400000007758,
    "number": 1060,
    "powMin": 69,
    "time": 1497003882,
    "medianTime": 1497001751,
    "membersCount": 7,
    "monetaryMass": 42000,
    "unitbase": 0,
    "issuersCount": 1,
    "issuersFrame": 6,
    "issuersFrameVar": 0,
    "currency": "g1-test",
    "issuer": "3dnbnYY9i2bHMQUGyFp5GVvJ2wBkVpus31cDJA5cfRpj",
    "signature": "/z4JXm8ZYMCPQzZlt1MyW/pVNaIknsK3G2a5KVj9NYW3FI7Jk+w3ThKPTW7Z+G3NWdqmzAwAbzrH14Coh6nyAw==",
    "hash": "00006EF25632371CB48CBEFC82D40BB121A56D8CDFF755696F2AEAD1B403FB81",
    "parameters": "",
    "previousHash": "0000A807F43DF6100F6D8FC27C4ED18647815FD0E3BE868E0A1DAB6423C053D8",
    "previousIssuer": "3dnbnYY9i2bHMQUGyFp5GVvJ2wBkVpus31cDJA5cfRpj",
    "inner_hash": "9D4CB3FF500FA37C3CC6CFB0572889DB7BF2B161AF8343DF1C0F8910210E02E6",
    "dividend": null,
    "identities": [],
    "joiners": [],
    "actives": [],
    "leavers": [],
    "revoked": [],
    "excluded": [],
    "certifications": [],
    "transactions": [],
    "raw": "Version: 10\nType: Block\nCurrency: g1-test\nNumber: 1060\nPoWMin: 69\nTime: 1497003882\nMedianTime: 1497001751\nUnitBase: 0\nIssuer: 3dnbnYY9i2bHMQUGyFp5GVvJ2wBkVpus31cDJA5cfRpj\nIssuersFrame: 6\nIssuersFrameVar: 0\nDifferentIssuersCount: 1\nPreviousHash: 0000A807F43DF6100F6D8FC27C4ED18647815FD0E3BE868E0A1DAB6423C053D8\nPreviousIssuer: 3dnbnYY9i2bHMQUGyFp5GVvJ2wBkVpus31cDJA5cfRpj\nMembersCount: 7\nIdentities:\nJoiners:\nActives:\nLeavers:\nRevoked:\nExcluded:\nCertifications:\nTransactions:\nInnerHash: 9D4CB3FF500FA37C3CC6CFB0572889DB7BF2B161AF8343DF1C0F8910210E02E6\nNonce: 10400000007758\n"
  }

vincentux · 26 September 2017 10:26

maintenant j’ai plutôt ça :

https://framabin.org/?747fcb901557d616#6H+Oj/y7G2O1GVXB2UfhrgDzuns0eMVAs5SHOH1bx5E=

kimamila · 26 September 2017 14:12

Je crois que je dois essayer d’indexer trop vite, alors que le cluster n’est pas ready.
Cependant, tes derniers logs @vincentux ont l’air mieux : l’indexation de la BC me semble passée.
Pour vérifier : Depuis un navigateur, peux tu faire un http://localhost:9200/g1-test/block/current ?

vincentux · 27 September 2017 07:24

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 :

kimamila · 27 September 2017 07:28

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 ?

vincentux · 27 September 2017 07:31

ok, ça doit être 9202, sur cette ligne alors ?

kimamila · 27 September 2017 07:31

Yes !

kimamila · 3 October 2017 22:21

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.

Fonctionnement

Au démarrage du noeud ES, une synchronisation est faite à partir des noeuds Duniter déclarant les API ES_USER_API et ES_SUBSCRIPTION_API dans leurs endpoints.
- Il est également possible de configurer un liste figée de endpoints, et de désactiver le crawler.
A la fin de la 1ere synchronisation, une WebSocket est ouverte pour écouter tous les changement du noeud, qui sont alors reporté sur le noeud (après vérification du respects des règles des documents : signature, hash, etc.)
Toutes les heures, les connexion WebSocket sont fermées, pour :
- Actualiser la listes des endpoints du réseau (détection des nouveaux endpoints dont l’API est compatible)
- Relancer une synchronisation sur ces endpoints (uniquement un delta à partir de l’heure des documents, en appliquant toutefois une marge d’erreur sur l’heure) ;
- puis on réouvre les WebSockets

etc.

N’hésitez pas à commenter/questionner cette solution.

Ğ1 > 2 noeuds Cesium+/ES !

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 :

Cesium : https://g1.le-sou.org,
Noeud Duniter (v1.6.8) : https://g1.le-sou.org/node/summary
Noeud ES : https://g1.data.le-sou.org

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)

elois · 3 October 2017 22:36

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

kimamila · 4 October 2017 12:41

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 :

Côté Cesium : corriger le bug, afin de mettre à jour systématiquement le champstime;
Côté ES : ajouter une règle de contrôle, afin que 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 :

le noeud ES autorise un décalage maximal (configurable) du time, dans des documents reçus;
lors d’une synchro différentiel, on interrroge les autres noeuds en premant un délai de sécurité : potentiellement trop de documents sont ramenés, mais on fait ensuite un tri est fait à l’aide de 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