MySQL --- Problem mit Sleep-Prozessen

ich seh das auch alles ein, kein problem. ich versuche es auch oft mit nachlesen, nur leider gehts mir dann immer so, das ich so viele mögliche lösungen sehe, und irgendwas betreitet mir dann immer sorgen. so wie jetzt z.B. *fg*

ich hab jetzt denk ich verstanden, das ich "mysqld --log" benötige, damit sich bei mir im data ordner so was wie eine allwissende datei auftut :mrgreen:

ich überleg halt immer viel zu viel, was denn alles schief laufen könnte :oops:

Und ich bin halt einfach verwirrt, weil ich mir beim besten willen nicht vorstellen kann, woher der fehler nun letztendlich kommt. Weil ja bei dem Slot immer wieder die eine Datei aufgerufen wird, die eigentlich im Grunde alle mysql-abfragen immer wieder ausführt, und irgendwann bleibt halt was "hängen"
 
So, jetzt wirds richtig Spannend :mrgreen:

Hab vorhin weng ahnungslos rumprobiert, einfach ma den log eingeschaltet und wollte mal sehen, was er denn macht, wenn der fehler auftritt... Fehler kam net, also will ich den server wieder beenden, anscheinend war ich da etwas zu schnell... buchungs-tabelle laut myphpadmin irreparabel kaputt :(

Ich habs einfach ma net geglaubt, und irgendwann auch festgestellt, das da eine TMD statt einer MYD datei liegt. umbenannt probiert, hier und da noch was gemacht ging wieder.

Aber weiterhin: kein fehler an mehr an dem Slot.

ich hab in dem thread hier irgendwann mal erwähnt, das ich da auch schon probleme hatte, weil die datenbank so voll war, nur das da nirgendwo mehr ein eintrag gemacht wurde.
Kann das zusammenhängen?
Darauf gekommen bin ich, weil mir eingefallen ist, das ich gestern wieder mal die alten buchungen gelöscht habe.

Wenn das wirklich daran liegen kann. was kann ich dann tun, damit ich das problem nicht mehr bekomme?
 
Werewolf schrieb:
Hab vorhin weng ahnungslos rumprobiert, einfach ma den log eingeschaltet und wollte mal sehen, was er denn macht, wenn der fehler auftritt... Fehler kam net, also will ich den server wieder beenden, anscheinend war ich da etwas zu schnell... buchungs-tabelle laut myphpadmin irreparabel kaputt :(
Zum Vergrößern anklicken....

ich würde dir wirklich ans Herz zu legen, die einen Technicker zu holen, dem du nen paar Euro für das Server überwachen zahlst, denn schnell ist mal was falsch gemacht und es sind mal wirklich wichtige Daten kaputt, was meinst du wie laut dein geschrei wird wenn auf einmal eine ganze datenbank crasht und die nicht mehr wiederherstellbar ist?
 
backup? *hehe*

und es war dann doch nicht an der zu vollen tabelle gelegen, der fehler ist wieder da...

und nein: ich werde kein geld dafür ausgeben, schließlich haben es techniker ja auch mal gelernt

aber ich seh schon, das posten hier lass ich nun besser auch ma.
 
es war in dem fall nur die buchungsliste, da hätte ich nicht besonders viel verloren

und backups sind ja auch da, nur greife ich auf die immer erst zu, wenn gar nichts mehr geht

is doch auch egal grad, problem ist jeden falls immernoch da

an den datenbank-queries liegts ma sicher net,

am php-script kann ich mir auch keinen fehler vorstellen, und den Bauherren des Slots hab ich auch noch net gefunden
 
Es lag am Programm, das mit dem Slot mitgeliefert war (also dann doch kein mysql-problem)

Und zwar war da in der Gewinnberechnungs-Schleife die abfrage, ob die "ershuffelten" symbole nen JackPot-Ergeben.

Wenn das True war, dann wurde gefragt, ob der jackpot auch schon die fallgrenze erreicht hat.

Wenn da jetzt False zurückgeliefert wurde stand da, das der gewinn (welcher 99999999 ist, laut config) vom gewinnpott abgezogen werden soll.

Also war der gewinnpot ab da im minusbereich, wurde auch im laufe des ganzen scripts nie wieder geändert, ausser eben, wenn wieder mal abgezogen wurde *g*

Da nun aber die schleife am ende (is ne do... while schleife) abfragt, ob der gewinn größer ist als der topf war damit die endlos schleife geboren.

ich hab dieses script mal mit anderen Slots verglichen, und muss sagen, da hat der progger allgemein ziemlich mist gebaut.

Funktioniert zwar jetzt, aber das wahre ist es nicht gerade
 
Werewolf schrieb:
Also war der gewinnpot ab da im minusbereich, wurde auch im laufe des ganzen scripts nie wieder geändert, ausser eben, wenn wieder mal abgezogen wurde *g*
Zum Vergrößern anklicken....
öhm, irgendwie fühle ich mich verarscht :roll:
genau das habe ich hier einige Posts vorher gesagt, und der PHP Parser hätte eigentlich auch einen Fehler loggen müssen


Edit: der Post fehlt komplett, dabei war der recht lang :( wahrscheinlich mal wieder kurz das netz rausgeflogen und ich habs net gemerkt
 
Zuletzt bearbeitet:
Hehe ... ich konnte mich auch daran erinnern, das mit dem Minusbereich gelesen zu haben ;)

Werewolf schrieb:
ich hab dieses script mal mit anderen Slots verglichen, und muss sagen, da hat der progger allgemein ziemlich mist gebaut.
Zum Vergrößern anklicken....

Hehe ... ich hab ja schon viele Codes von Slots gesehen und ich muss sagen, es ist die REGEL daß da Mist geschrieben ist. In der Regel braucht da nur das geringste schief zu laufen und schon kann der Code es nicht abfangen.

Das Problem mit dem Minus kannte ich auch schon. In meinem neuen Losescript hab ich daher aus all diesen Gründen einen neuen Code geschrieben, den ich für die Slots benutze, das Prinzip ist ja im Grunde immer das selbe, das unterschiedliche Verhalten vieler Slots steuere ich durch Variablen. So bin ich sogar in der Lage, Slots eigene Gewinnpots je Stufe zu verpassen oder andere nette Features zu integrieren, die der eine oder andere Slots womöglich nicht hat als auch Bugs der Slots zu korrigieren. Nur zwei Beispiele: Beim Sportslot kommt in der ersten Spalte das Jokersymbol, obwohl es dort nicht gezählt wird und beim Safari kann es passieren, daß zwei Linien Gewinntreffer erzielen obwohl dieser nur über eine Gewinnlinie verfügt.

So kann ich Bugs sogar zentral ausbessern! :D

Falls jemand das Minusproblem vieler Slots angehen möchte: Ich hab mir darüber Gedanken gemacht, mit Locking-Mechanismen oder ähnliches zu arbeiten um erst gar kein Minus zu erlauben. Allerdings bin ich zu dem Schluss gekommen, daß es nicht weiter schlimm ist, wenn bei zwei Updates zugleich der eine den Pott ins Minus bringt, da dieser ja anschließend wieder ausgeglichen wird. Wichtig ist es hier allerdings darauf zu achten, daß das Script nicht in eine Endlosschleife gerät und daß das Datenbankfeld auf keinen Fall UNSIGNED ist, da man somit einen Überlauf generiert (auch schon mal in einem Slot gesehen, weiß gerade nicht welchen) und den Pott mit hübschen Millionen füllt, denen man nachher nachtrauen könnte *g*

Allgemein muss ich sagen/warnen, vieles ist in diesem Bereich soooo schlecht programmiert, daß man doch im Grunde, würde man böse sein und die ganzen unzählichen Bugs ausnutzen, viele Webmaster doch um eine Menge Lose betrügen könnte.
 
SpecialsGuy schrieb:
Allgemein muss ich sagen/warnen, vieles ist in diesem Bereich soooo schlecht programmiert, daß man doch im Grunde, würde man böse sein und die ganzen unzählichen Bugs ausnutzen, viele Webmaster doch um eine Menge Lose betrügen könnte.
Zum Vergrößern anklicken....

Das gilt leider nicht nur für Slots, sondern für viele Webseiten, die man hier so sieht. PHP wird halt selten alleine gelernt, allgemeines "Programmierwissen" (insbesondere die Sicherheit in Anwendungen) steht da nicht so hoch im Kurs.

Ever trust user input ;)

Wenn dann mal PHP 6 ohne magic_quotes* kommt, dann werden sich einige bestimmt mit Hilfe dieser Scripte bereichern ...
 
ist es dann nicht möglich (falls jemand seine eingaben nicht sichert) ziemlich einfach, beliebigen Code zum Scipt hinzuzufügen?

Warscheinlich war die aussage nun absoluter blödsinn -.-
 
ice-breaker schrieb:
da wird sich endlich die Spreu vom Weizen trennen, nur wird es wieder lange dauern bis PHP6 überall unterstützt wird
Zum Vergrößern anklicken....

Ich hasse diese ständige Abänderungen in PHP ... die sollen einfach mal eine vernünftige Sprache machen, die dann auch so funktioniert und woran dann an den Grundregeln der Sprache nicht mehr gerüttelt wird. So wie es in anderen _richtigen_ Sprachen auch der Fall ist!

Das ist allein einer von vielen Gründen, wieso ich PHP für eigene Sachen meide und lieber auf Perl setze (so wie viele andere eigentlich auch).
 
Werewolf schrieb:
ist es dann nicht möglich (falls jemand seine eingaben nicht sichert) ziemlich einfach, beliebigen Code zum Scipt hinzuzufügen
Zum Vergrößern anklicken....
ja, mann kann relativ ienfach code einschlueßen, allersings hat PHP da auch schutzfunktionen, aber diese sind eben nicht allmächtig

SpecialsGuy schrieb:
Ich hasse diese ständige Abänderungen in PHP ... die sollen einfach mal eine vernünftige Sprache machen, die dann auch so funktioniert und woran dann an den Grundregeln der Sprache nicht mehr gerüttelt wird. So wie es in anderen _richtigen_ Sprachen auch der Fall ist!

Das ist allein einer von vielen Gründen, wieso ich PHP für eigene Sachen meide und lieber auf Perl setze (so wie viele andere eigentlich auch).
Zum Vergrößern anklicken....
ja, wenn PHP mal fertig wäre, wäre das wirklich schön, aber PHP wird eben auch ständig weiterentwickelt, das ist eben schön, und man hatte zu Anfang ja noch nichmal absehen können, was aus PHP wird. Mit PHP5 haben sie nun endlich das OOP mal ordentlich umgesetzt und mir PHP6 wird der Code aufgeräumt, ich werte das als gutes Zeichen, dass wir uns dem Ende nähern, denn soviel gibt es in PHP nicht mehr zu machen, das OOP nach Java-Vorbild beenden, und dann braucht man ja kaum nochwas. Die sollen sich ja nur net komplett an java anlehnen, dass es nur noch feste rückgabe-typen von funktionen gibt und stattdessen exceptions auslösen, denn das hasse ich in java
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

Zicklein444
Umfragen, technisches Problem
Antworten
3
Aufrufe
589
Zicklein444
Zicklein444
domino
Problem bei »Alle Cookies aktivieren.«
Antworten
1
Aufrufe
2K
klamm
klamm
Zurück
Oben