Sakia 0.33.0 - Compatibilité WS2P

Oui j’ai remarqué que les synchro ont ralenti.

Je pense avoir compris d’ou ça vient. Il y a beaucoup (BEAUCOUP) de noeuds avec BMA incorrectement configuré. Sakia se prends les pieds dans le tapis, car une grande part de ses requêtes échouent à cause de ça.

Je vais travailler dessus.

Il est synchronisé sur 12h34 aujourd’hui (heure où j’ai ajouté mes identités) et il est 17h40.
Il ne synchronise que lorsque j’ajoute une identité. Ensuite plus rien.

DEBUG:node:request_ws2p_heads:[BoZP6] Could not connect to any BMA endpoint

L’icône de rafraîchissement en bas à gauche est elle en train de tourner ? Normalement sakia se synchronise tout seul, sans avoir à ajouter de compte. Essaye d’attendre un peu, ça peut mettre du temps (cf mon post précédent)

Il tourne puis il ne tourne plus et ne met pas à jour.
En fait je vais utiliser Césium parce que si à chaque fois que je veux vérifier une donnée en 30 secondes il me faut attendre 2 jours, ça va pas.

Bonsoir,

Suis un peu à la traîne, occupé ces deux derniers jours.
Merci beaucoup @Inso pour les explications.

Est-ce que ces dernières évolutions auraient également des implications pour le logiciel Duniter ?
Une sensation, en tout cas sur mon ordi, de davantage de vélocité.

Très bonne soirée à tous.

Un message a été intégré dans un sujet existant : Comment se faire connaître pour être certifié en étant expatrié

Release de la 0.33.0rc3. J’ai revu un peu l’algorithme de Circuit Breaker que j’utilise. Dorénavant :

  • Au delà de 3 erreurs lors des requêtes, le noeud est considéré « offline » par sakia (en rouge dans le réseau)
  • Sakia tentera quand même de requêter un noeud offline en plus de 3 noeuds online lorsqu’il fera ses requêtes, afin de vérifier si il est revenu ou non
  • Si le noeud diffuse une nouvelle fiche de pair, sakia fera là aussi remonter le noeud en vert, jusqu’à ce que des requêtes échoue à nouveau
  • La vérification ne s’appuie plus sur 6 noeuds mais sur 3 noeuds
  • La vérification ne s’appuie plus uniquement sur les noeuds membres. C’est un rééquilibrage entre sécurité et performances… A voir vos retours.

J’ai aussi revu l’algorithme d’affichage de la WoT. C’était devenu là aussi inutilisable avec l’agrandissement du réseau et des certifications. Auparavant, je requêtais les données d’identités sur tous les certifieurs/certifiés affichés. Dorénavant, que la personne ait 25 ou 5 certifications, ça prendra le même temps d’affichage, je n’utilise plus que les données présentes dans les requêtes certifiers-of , certified-by , lookup .

A noter que j’ai un problème avec les releases Windows, qui ont arrêté de fonctionner. Ca va me prendre du temps à analyser… :frowning:

3 Likes

Voici les erreurs de sakia 0.33.0 rc3


Task exception was never retrieved
future: <Task finished coro=<BlockchainService.handle_blockchain_progress() done, defined at sakia/services/blockchain.py:54> exception=AttributeError("'NoneType' object has no attribute 'currency'",)>

----
Traceback (most recent call last):

  File "asyncio/tasks.py", line 240, in _step

  File "sakia/services/blockchain.py", line 71, in handle_blockchain_progress

  File "sakia/services/identities.py", line 477, in handle_new_blocks

  File "sakia/services/identities.py", line 466, in parse_block

  File "sakia/services/identities.py", line 409, in _parse_certifications

  File "sakia/data/processors/certifications.py", line 35, in drop_expired

AttributeError: 'NoneType' object has no attribute 'currency'

Sur quel réseau ?

C’est très étrange comme bug. Tu devrais supprimer les connexions concernant des identités et les rajouter à nouveau. Je pense que dans la version précédente, avec le Circuit Breaker mal calibré, ça a intégré des données incorrects dans ta base.

@Inso je vais essayer ça !

ça reste extrêmement lent… en 0.33.0rc3 aussi…

oui 1h pour synchroniser mon compte membre
je viens d’en ajouter un autre non membre cette fois, ça devrait aller plus vite, ah ben c’est fait : 5 mn

Le time remaining est largement sous-estimé

@Inso, ça marche j’ai donc supprimé le dossier .config/sakia et relancé, je n’ai plus de messages d’erreur intempestifs et la synchro se fait régulièrement. Merci.

1 Like

Oui, il faudra attendre les travaux de nanocryk pour aller plus loin dans des mécanismes de vérification plus rapide. :slight_smile:

J’ai corrigé les builds pour windows : https://github.com/duniter/sakia/releases/tag/0.33.0rc4

2 Likes

par contre j’ai ajouté une dizaine de comptes dont la moitié membres dans sakia et à un moment le blocage est revenu, c’est 0.33rc3.
J’ai donc supprimé les comptes et je les ajoute lentement et entre chaque ajout je vérifie si tout marche pendant quelques heures. Le but étant de savoir exactement sur quel compte les messages d’erreurs et le blocage des synchro surviennent.

Je vous tiens au courant.

1 Like

@inso je pense avoir trouvé ce qui corrompt sakia :
J’ai ajouté une connexion avec une clé publique qui a 2 identités avec le même pseudo.
mateo@8Lk4w4j2idRyC9X1geuchdEHemz9S3AsHJ2oJD3kG5Au
dès que je veux supprimer cette connexion, j’ai des messages d’erreurs, elle se supprime mais ensuite mon sakia est buggué et affiche de nombreux messages d’erreurs même au démarrage et il ne synchronise plus jamais jusqu’à ce que je le réinitialise et remette mes connexions en place.

Voilà. Si ça peut aider …

1 Like

Je veux bien un rapport de bug sur le gitlab. Je regarderai quand j’aurais le temps (donc pas tout de suite)

@inso ok c’est fait !

Alors j’ai réussi miraculeusement à trouver du temps cette semaine pour bosser un peu sur Sakia, alors je vous offre une grosse release aujourd’hui avec la 0.33.0rc6 : https://github.com/duniter/sakia/releases/tag/0.33.0rc6

Cette release :

  • Corrige le problème de chargement extrêmement long des données initiales des comptes dans Sakia
  • Accélère de manière générale le rafraichissement des données
  • Corrige un bug critique qui faussait le montant de monnaie disponible sur les comptes.

A noter que la contrepartie de ce gain en performance est que les dates sont dorénavant moins précises de manière générale. Plutôt que de demander au réseau, pour chaque donnée blockstampée, “à quelle timestamp tel block a été généré”, Sakia va dorénavant calculer de lui même un timestamp moyen via la variable “avg_gen_time” qui est de 6 minutes sur la Ğ1. Ainsi, une donnée écrite il y a 10 blocks sera inscrite dans la BDD sakia avec le timestamp courant moins une heure (10*6 minutes).

Un autre changement de comportement important est le suivant : Lors de l’initialisation d’un compte, sakia ne récupère les transactions que des 30 derniers jours au lieu de l’historique complet de la chaine.

N’hésitez pas à me faire vos retours sur cette version !

4 Likes

Tu n’aurais pas le .deb ?