Serialization failure: aie aie ai !!! Deadlock

[srm]

Oublie les transactions et met un système de queue.
Je t'ai dit qu'il fallait des transactions courtes, tu me dis que la tienne est immense.

[php_addict]

oui la mienne est immense, transaction of course, bref...

oui faut que je passe par un système de queue schedulding, la vache c'est du taf en plus ca, faut que j'installe un débian sur un vieux pc pourrage pour tester tout ca...galère...

pour le moment ca devrait tenir la route car etant donné que je n'ai qu'une seule transaction dans tout mon code et qu'il y a un rollback, alors il ne devrait pas y avoir de probleme si le rollback fait bien son boulot, enfin j'espère...

c'est quand même bien con que mysql ne puisse pas dire quels sont les lignes du codes des 2 transactions qui sont en dealock, 'fin je veut dire la transaction qui lock et celle qui est en dealock...

bon je vais me lancer dans le queue schedulding, je savais bien qu'un jour il fallait que j'y passe, mais ca m'enchante guère...

je vais tester dans un premier temps php resque schedulding. y a t il d'autres système que resque sachant qu'il me faut des schedulding à la seconde près...?

'tain faut que j'installe un serveur, tout ce que j'aime pas...bon c'est du local donc ca va pas être trop chiant, j'aime pas le mode console, beark

merci

++

[Sephi-Chan]

Ne sois pas si désinvolte, c'est une très bonne chose. De plus, ton code en sortira simplifié.

En revanche, garde en tête qu'aucun système de scheduling/queueing ne te garantira le moment d'exécution : il te garantie seulement que la tâche sera ajoutée à la queue à cet instant. Si aucun worker n'est disponible, ça peut prendre un peu plus de temps. Le plus souvent ça n'est pas le cas (tant que tu dépiles plus vite que tu n'empiles), mais ça peut arriver. Enfin, je doute qu'un retard d'une seconde (ou un peu plus) soit réellement critique.

[php_addict]

ce qui est primordial est l'ordre de résolution des actions, que les actions soient résolues aux timestamps précis même si ce que voient les joueurs peut ne pas correspondre aux données du jeu qui elles doivent être intègres.

par contre ca peut être vachement embêtent pour l'expérience utilisateur si:

- le joueur lance une attaque via un <form> html
- l'action "mouvement de troupe/attaquer" est ajoutée à la queue
- la page est rafraichie lors du clic sur <submit>
- l'action est résolue par le schedulder , c'est à dire, on ôte les troupes du village car elle ne sont plus dans le village mais en mouvement

dans ce cas, si le joueur lance une attaque et qu'il ne voit pas ses troupes en mouvement c'est vraiment pas terrible, il y a un retard de l'affichage par rapport à l'état réel du jeu, ca c'est vraiment pas du tout cool...je sais pas si mon exemple est très clair...

il peut vraiment y avoir des retards d'affichage par rapport à l'état réel du jeu quand par exemple il y a on va dire 100 actions à résoudre au même moment, ou si le serveur met plusieurs secondes à résoudre des actions pour toutes autres raisons de ralentissement du serveur...

question annexe: comment savoir comment les "grand jeux" genre ogame et compagnie font? est ce réellement ce type de technologie utilisée (queue schedulding)?

Je n'ai jamais vu de retard d'affichage sur les jeux auxquels j'ai pu jouer, donc je me demande réellement si ils utilisent des queue schedulding à vrai dire...

[niahoo]

Tu as une seule requête avec transaction mais peut-être que deux requêtes web la lancent en même temps ?

Quoi qu'il en soit, un système de queue sera sympa. et à la seconde près, c'est possible.

[php_addict]

Ne sois pas si désinvolte, c'est une très bonne chose. De plus, ton code en sortira simplifié.

pourquoi simplifié en serait le code? (oulala ca fait un peu star wars cette phrase...)

je me suis dis ceci:

-lors de l'ajout d'un action (on enregistre en base de donnée l'action) et on met egalement dans la queue (redis/resque) cette action, de telle sorte qu'il y ai un enregistrement en dur (mysql) et un enregistrement en RAM (redis/resque) des actions, genre en cas de plantage serveur, ou redémarrage serveur, on a pas trop le choix en fait je crois...

ainsi les actions peuvent etre resolues de façon synchrone (rafraichissement de page) quand le système de queue est off ou down, et de façon assynchrone quand le système de queue est operationel. Le hic c'est de switcher de l'un à l'autre...euh je sais pas si c'est très clair...

le cas le plus pourri etant:

- on a une queue d'action bien foutue, des actions à résoudre, tout se passe bien. les workers feront le job...
- le serveur plante, ou redemarre et crac! la ram de redis est vide, les actions à resoudre ne sont plus dans la queue
==> ca se passe comment, il faut bien recharger les actions dans la queue (d'où l'utilité de les avoir sauvegardées en base mysql....)

comprends pas comment il est possible de determiner "je resoud assynchrone" ou "synchrone"...

vous me suivez? ou je délire totalement?

Tu as une seule requête avec transaction mais peut-être que deux requêtes web la lancent en même temps ?

oui c'est forcement ca à y bien penser...et du coup ma transaction fait bien son job, à savoir éviter les concurences d'accès à la base de donnée, donc ce genre de deadlock est vital pour l'integrité des données des actions à résoudre...

PS: bon ca y est mon serveur dédié est installé sur mon vieux pc tout pourrage, je vais pouvoir tester php resque tranquillement, ca va etre quand même bien chaud cette histoire de jobs schedulding...

[niahoo]

Elle fait son job, mais si tu dois modifier ton système pour que chaque transaction attende que la précédente ait fini son boulot alors en gros ton jeu ne sait servir qu'une requête à la fois

Bonne chance pour ton serveur, debian est un très bon système, pas si compliqué. Je te conseille cette excellente ressource : http://formation-debian.via.ecp.fr/

Je pense également que pour ton premier serveur tu devrais même installer l'interface graphique et un bureau (GNOME, KDE, perso c'est XFCE qui me convient) mais sans que ça soit une excuse pour te passer de la ligne de commande le plus possible. La ligne de commande, une fois que tu sais un peu te dépatouiller ça change la vie par rapport à windows.

[srm]

Tu ne mets pas en ram ce que tu ne peux te permettre de perdre, exit REDIS pour la queue.

[php_addict]

ah ba zut, pas de Redis alors...j’étais chaud bouillant pour m'y coller

faut que je me trouve un autre système de queue alors? qui n'utilise pas la RAM...hum hum pas facile...

à bien y réfléchir il faudrait presque que je me fasse un deamon en C++, lancer au démarrage du serveur donc, et qui n'enregistre qu'un seul timestamp, celui de la prochaine action à résoudre, et à ce timestamp donné le deamon lance la résolution d'action (je sais pas si un programme C peut lancer un script php) puis attend le prochain timestamp...j'y connais rien du totu en C donc c'est chaud quand même...

[Sephi-Chan]

Mais pourquoi est-ce que tu vas toujours trop loin... -.-

Ensuite, ton histoire de bascule synchrone/asynchrone n'est absolument pas nécessaire. Pourquoi veux-tu que la queue arrête de fonctionner ? Est-ce que tu traites le cas où ton serveur Web cesse de fonctionner ? Ou que tes workers FCGI (si tu en utilises) cessent de fonctionner ?

Utilise simplement l'outil et traite les problèmes très spécifiques quand ils surviennent.

Et par pitié, réfléchis à la criticité d'une perte de données. Est-ce que c'est vraiment si grave si tu perds le fait qu'un joueur a lancé telle action ? En sachant que si c'est arrivé, c'est que ton serveur est tombé, et donc que tu as des problèmes autrement plus grave à régler, et que le scheduler va relancer les tâches supposées être passées.

Ton goût systématique pour la complexité inutile me laisse perplexe. Comme si on avait pas des problèmes réels (temps, motivation, moyens, etc.) pour ne pas avoir besoin de s'en inventer de nouveau.


PS : On peut utiliser Redis en mode écriture sur le disque, mais ce n'est pas forcément pertinent.