Hello, Bogdan!

Yes, in the log i noticed only one dr_reload when the problem appears.
I wanted to show that opensips tries to make many attempts to connect to mysql 
but dr_rules becomes empty.

Next dr_reload had been applied over 9 minutes about.

mailto:[email protected]


Hi Denis,

The log you attached shows one single dr_reload command received, leading to 
the load of 198 GWs. After that there are no logs related to DR at all.

Regards,
Bogdan
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 27.09.2016 09:47, Denis wrote:

Re: [OpenSIPS-Users] Opensips 2.2.1 dr_rules is empty Hello, Liviu!

The problem is still active.
In attachment you can see the latest log of the problem.

After the last string mysql connection became correct.

I want to ask, does it make any sense to increase timer parameters for mysql 
connection.
Ok, suppose we have some problem with the server and increasing of  timer 
parameters will help for it, but why does dr_rules becomes empty if it has 
mysql connection problem?


mailto:[email protected]


Correct, Denis - they have nothing to do with each other. I am just trying to 
isolate our problem (by excluding "too many reconnects"), so we can better 
understand what's happening.
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 12.09.2016 15:45, Denis wrote:

Re: [OpenSIPS-Users] Opensips 2.2.1 dr_rules is empty Liviu, and one 
interesting thing.
if we have some problem with mysql connection, why does dr_rules becomes 
"empty"?

mailto:[email protected]


Since you are using OpenSIPS 2.2, you can tune the following modparams of 
"db_mysql" [1], and see if behavior improves:
- max_db_queries (how many times a query is attempted)
- max_db_retries (for each query attempt above ^, how many attempts to connect 
to the MySQL server)

[1]: http://www.opensips.org/html/docs/modules/2.2.x/db_mysql.html#id249634
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 12.09.2016 13:02, Denis wrote:

Re: [OpenSIPS-Users] Opensips 2.2.1 dr_rules is empty Hello,. Liviu!

I saw in log "too many reconnects". Unfortunately it does not reflected in log 
files that i attached early but it was there.
So.
I have two servers with two mysql + Opensips  installation. As you probably 
gassed one server is active and another is stand by. 
Active server has "Server version: 5.5.50-0ubuntu0.12.04.1-log (Ubuntu)" mysql 
installation and standby  server has "Server version: 
5.5.44-0ubuntu0.14.04.1-log (Ubuntu)" mysql installation.
Respectively active server has "Ubuntu 12.04.5 LTS precise" and standby has 
"Ubuntu 14.04.3 LTS trusty"
Mysql replication master-master has been customized between two servers.

mailto:[email protected]


Hi Denis,
Looking through the logs, this one seems to be relevant, and we need to 
understand the root cause for why it's happening:
Aug 19 17:00:37 opensips-main /usr/local/opensips2.1/sbin/opensips[17749]: 
WARNING:drouting:dr_load_routing_info: table "ast_dr_rules" is empty

As far as I can understand, one "dr_reload" command finds the table empty, then 
the next one properly retrieves the data! Although I see several disconnect 
events in there (for each process!), the driver should have reported "too many 
reconnects" errors if those were really the cause.

Could you provide more info about your MySQL setup? Is it a server, slave or 
cluster? What software and what version?
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com
On 09.09.2016 09:19, Denis wrote:

Re: [OpenSIPS-Users] Opensips 2.2.1 dr_rules is empty Hello!

Any ideas about the problem?

mailto:[email protected]



Hello, Bogdan

I am sorry that i did not describe the problem more clearly.
404 opensips sends because in opensips.cfg i wrote a logic that if in dr_rules 
opensips finds no rules for routing it must send 404.
And the problem i think is there. Opensips began rejects all calls with 404, 
i.e. it could not find any rules in dr_rules table.
Everthing began fine after fifo dr_reload command execution, i.e. after 
dr_rules updating.   

-- 
mailto:[email protected]


Hi,

OpenSIPS by itself does not send any 404. If it does, it does it because you 
put that into the script. So, you have to look into your script and see the 
logical path that makes OpenSIPS to get to sending a 404 reply.

You may use the script_trace :
http://www.opensips.org/Documentation/Script-CoreFunctions-2-2#toc43

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 30.08.2016 22:26, Denis wrote:

Re: Opensips 2.2.1 dr_rules is empty Hello!

Some time ago i wrote about a problem when Opensips began reject all calls with 
404 code.
Unfortunately i did not received any answer.
Since that time i have made upgrade from 2.1.2 to 2.2.1 and today i have got 
the same problem. Opensips began rejects all calls with 404 code. 

Based on the information from log, i make suggest that problem began when 
dr_reload command has been received. 
And the problem has been solved, again, when the dr_reload command has been 
received (the period about two commands is about a couple of minutes).

I please help to solve the problem. 

Thank you.

mailto:[email protected]


Hello!

Recently i begun to get such problem.
Opensips rejects all calls with 404 code. I can solve the problem by making 
dr_reload.
I tried to analyze a log and what i could found you can see in attachment.
As i could understand last problem began after dr_reload.

Thank you for any help.


mailto:[email protected]







_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________

Users mailing list

[email protected]

http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to