[SR-Users] kamailio crash after sqlops failures

[Uri Shacked]

Hi,

I do use SQL query in several places.

1. In the failure route to insert an event to the local DB where ACC
module does not do it. It is an insert to the local server DB and
seems to be very fast.

2. In the "event_route[*dialog:end*]" I call a procedure to delete a
row based on the callid as primary key. This is on the central DB and
might be slow when the DB is down or network is slow.

2. In the "event_route[*dialog:failure*]" I call a procedure to delete
a row based on the callid as primary key. This is on the central DB
and might be slow when the DB is down or network is slow.

Thanks,

Uri

>Hello,
>
>do you call any sql query in failure routes?
>
>I want to see of worth looking at if the query is too slow for the
>transaction to stay in memory after there is a final response to it.
>
>Cheers,
>Daniel




On Thu, Jan 16, 2014 at 12:51 PM, Uri Shacked <ushacked at gmail.com> wrote:

>
> Daniel hi,
>
>
>
> I attached the following file:
>
> 1.       "bt full" and "log" for each of the 3 servers.
>
> 2.       The central MySQL slow queries log
>
> 3.       The var/log/messages from one server.
>
>
>
> The servers crashed at different times but:
>
> 1.       The MySQL server was very slow between 16:10:00 till 16:12:00
> (approximately).
>
> 2.       On each server, I am pretty sure, kamailio crashed while doing
> the data reload from modules like MTREE, HTABLE, DIALPLAN and CARRIERROUTE
> (all and all round 100,000 rows).
>
> Thanks again,
>
> Uri
>
>
> On Thu, Jan 16, 2014 at 2:17 AM, Daniel-Constantin Mierla <
> daniel at asipto.com> wrote:
>
>>  Hello,
>>
>> the backtrace shows a crash in tm module, not sqlops.
>>
>> Can you tell which of the log files correspond to the instance that
>> produced the core file from where you took the back trace you attached?
>>
>> Can you give the backtraces from all cores? You say there were 3 crashes.
>> It is important to see if the backtrace is the same everywhere.
>>
>> Cheers,
>> Daniel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20140119/374d4e43/attachment.html>