Hi,
eine Frage an Euch:
ich habe eine Debian-Box Etch 2.6.18-6-686 mit einer bristuff-version 1.2.30-BRIstuffed-0.3.0-PRE-1y-u.
Heute trat folgendes Problem auf:
Iirgendwann gegen Mittag bekamm ich einige Deadlocks (channel.c: Avoided initial deadlock for '0x813c920', 9 retries!).
Danach lief der Ast zwar und augenscheilich war alles in Ordnung (peers connected) - ABER: Kein einziger Channel konnte aufgebaut werden!
app_dial.c: Unable to create channel of type 'SIP'
Erst nach dem Neustart des Ast war wieder alles oK!!!!
Meine Vermutung: Könnte es an der cdr_addon_mysql liegen?? Bekomme ich den Deadlock vom MYSQL-Connect??
ist cdr_odbc stabiler? bzw. grundsätzilch dem cdr_addon_mysql vorzuziehen??
Für mich ziemlich bitter, weil etwa 70 Power-Phone-User auf der Anlage sitzen und jede Minute Ausfall für mich hardcore-Stress bedeutet!!!
Habt Ihr Ideen woher der Fehler kommt?
Ist der Zusammenhang mit dem Deadlock <--> MYSQL richtig?
Wie könnte ich das austesten bzw. dem Problem näher kommen??
thx
mex
eine Frage an Euch:
ich habe eine Debian-Box Etch 2.6.18-6-686 mit einer bristuff-version 1.2.30-BRIstuffed-0.3.0-PRE-1y-u.
Heute trat folgendes Problem auf:
Iirgendwann gegen Mittag bekamm ich einige Deadlocks (channel.c: Avoided initial deadlock for '0x813c920', 9 retries!).
Danach lief der Ast zwar und augenscheilich war alles in Ordnung (peers connected) - ABER: Kein einziger Channel konnte aufgebaut werden!
app_dial.c: Unable to create channel of type 'SIP'
Erst nach dem Neustart des Ast war wieder alles oK!!!!
Meine Vermutung: Könnte es an der cdr_addon_mysql liegen?? Bekomme ich den Deadlock vom MYSQL-Connect??
ist cdr_odbc stabiler? bzw. grundsätzilch dem cdr_addon_mysql vorzuziehen??
Für mich ziemlich bitter, weil etwa 70 Power-Phone-User auf der Anlage sitzen und jede Minute Ausfall für mich hardcore-Stress bedeutet!!!
Habt Ihr Ideen woher der Fehler kommt?
Ist der Zusammenhang mit dem Deadlock <--> MYSQL richtig?
Wie könnte ich das austesten bzw. dem Problem näher kommen??
thx
mex
