[OpenSIPS-Devel] [opensips] Inconsistency with dispatcher between live data & mysql database store (#711)
Yossi
notifications at github.com
Tue Dec 1 03:07:15 CET 2015
Compare the output from the same exact running opensips server:
PARTITION:: default
SET:: 1009
URI:: sip:216.X.X.141 state=Active
URI:: sip:216.X.X.142 state=Active
URI:: sip:216.X.X.146 state=Active
URI:: sip:216.X.X.147 state=Active
URI:: sip:216.X.X.148 state=Inactive
URI:: sip:216.X.X.149 state=Inactive
URI:: sip:216.X.X.171 state=Active
URI:: sip:216.X.X.172 state=Active
URI:: sip:216.X.X.173 state=Active
URI:: sip:216.X.X.174 state=Active
URI:: sip:216.X.X.175 state=Active
URI:: sip:216.X.X.176 state=Inactive
SET:: 2022
URI:: sip:216.X.X.164 state=Active
SET:: 1007
URI:: sip:216.X.X.139 state=Active
URI:: sip:216.X.X.141 state=Inactive
URI:: sip:216.X.X.142 state=Inactive
URI:: sip:216.X.X.146 state=Inactive
URI:: sip:216.X.X.147 state=Inactive
URI:: sip:216.X.X.170 state=Inactive
URI:: sip:216.X.X.171 state=Inactive
URI:: sip:216.X.X.172 state=Inactive
URI:: sip:216.X.X.173 state=Inactive
URI:: sip:216.X.X.174 state=Inactive
URI:: sip:216.X.X.175 state=Inactive
URI:: sip:216.X.X.177:5070 state=Active
SET:: 2018
URI:: sip:216.X.X.139 state=Active
SET:: 2017
URI:: sip:216.X.X.170 state=Active
SET:: 2015
URI:: sip:216.X.X.176 state=Active
attr:: 1000
SET:: 2014
URI:: sip:216.X.X.166 state=Active
SET:: 2013
URI:: sip:216.X.X.165 state=Active
SET:: 2010
URI:: sip:216.X.X.175 state=Active
SET:: 2009
URI:: sip:216.X.X.174 state=Inactive
SET:: 2008
URI:: sip:216.X.X.173 state=Active
SET:: 2007
URI:: sip:216.X.X.172 state=Active
attr:: 1000
SET:: 2006
URI:: sip:216.X.X.171 state=Active
SET:: 2005
URI:: sip:216.X.X.149 state=Active
SET:: 2004
URI:: sip:216.X.X.148 state=Active
SET:: 2003
URI:: sip:216.X.X.147 state=Active
SET:: 2002
URI:: sip:216.X.X.146 state=Active
SET:: 2001
URI:: sip:216.X.X.142 state=Active
SET:: 2000
URI:: sip:216.X.X.141 state=Active
SET:: 1001
URI:: sip:216.X.X.148 state=Active
attr:: 1000
URI:: sip:216.X.X.149 state=Active
attr:: 1000
URI:: sip:216.X.X.146 state=Inactive
attr:: 1000
URI:: sip:216.X.X.139 state=Inactive
attr:: 1000
URI:: sip:216.X.X.141 state=Inactive
attr:: 1000
URI:: sip:216.X.X.142 state=Inactive
attr:: 1000
URI:: sip:216.X.X.147 state=Inactive
attr:: 1000
URI:: sip:216.X.X.170 state=Inactive
attr:: 1000
URI:: sip:216.X.X.171 state=Inactive
attr:: 1000
URI:: sip:216.X.X.172 state=Inactive
attr:: 1000
URI:: sip:216.X.X.173 state=Inactive
attr:: 1000
URI:: sip:216.X.X.174 state=Inactive
attr:: 1000
URI:: sip:216.X.X.175 state=Inactive
attr:: 1000
SET:: 1000
URI:: sip:216.X.X.141 state=Active
URI:: sip:216.X.X.142 state=Active
URI:: sip:216.X.X.146 state=Active
URI:: sip:216.X.X.147 state=Active
URI:: sip:216.X.X.148 state=Inactive
URI:: sip:216.X.X.149 state=Inactive
URI:: sip:216.X.X.171 state=Active
URI:: sip:216.X.X.172 state=Active
URI:: sip:216.X.X.173 state=Active
URI:: sip:216.X.X.174 state=Active
URI:: sip:216.X.X.175 state=Active
URI:: sip:216.X.X.176 state=Inactive
URI:: sip:216.X.X.170 state=Active
URI:: sip:216.X.X.139 state=Active
ql> SELECT * FROM dispatcher WHERE setid=1001 ORDER BY state;
+-----+-------+--------------------+--------+-------+--------+----------+-------+--------------+
| id | setid | destination | socket | state | weight | priority |
attrs | description |
+-----+-------+--------------------+--------+-------+--------+----------+-------+--------------+
| 227 | 1001 | sip:216.X.X.148 | NULL | 0 | 1 | 0 | 1000
| Bah Cubes |
| 319 | 1001 | sip:216.X.X.170 | NULL | 0 | 1 | 0 | 1000
| Bah Cubes |
| 324 | 1001 | sip:216.X.X.175 | NULL | 0 | 1 | 0 | 1000
| Bah Cubes |
| 315 | 1001 | sip:216.X.X.139 | NULL | 0 | 1 | 0 | 1000
| Bah Cubes |
| 228 | 1001 | sip:216.X.X.149 | NULL | 0 | 1 | 0 | 1000
| Bah Cubes |
| 316 | 1001 | sip:216.X.X.141 | NULL | 1 | 1 | 0 | 1000
| Bah Cubes |
| 317 | 1001 | sip:216.X.X.142 | NULL | 1 | 1 | 0 | 1000
| Bah Cubes |
| 303 | 1001 | sip:216.X.X.146 | NULL | 1 | 1 | 0 | 1000
| Bah Cubes |
| 320 | 1001 | sip:216.X.X.171 | NULL | 1 | 1 | 0 | 1000
| Bah Cubes |
| 321 | 1001 | sip:216.X.X.172 | NULL | 1 | 1 | 0 | 1000
| Bah Cubes |
| 322 | 1001 | sip:216.X.X.173 | NULL | 1 | 1 | 0 | 1000
| Bah Cubes |
| 323 | 1001 | sip:216.X.X.174 | NULL | 1 | 1 | 0 | 1000
| Bah Cubes |
| 318 | 1001 | sip:216.X.X.147 | NULL | 1 | 1 | 0 | 1000
| Bah Cubes |
+-----+-------+--------------------+--------+-------+--------+----------+-------+--------------+
13 rows in set (0.00 sec)
mysql> SELECT * FROM dispatcher WHERE setid=1007 ORDER BY state;
+-----+-------+-------------------------+--------+-------+--------+----------+-------+---------------------------------------------+
| id | setid | destination | socket | state | weight | priority |
attrs | description |
+-----+-------+-------------------------+--------+-------+--------+----------+-------+---------------------------------------------+
| 304 | 1007 | sip:216.X.X.139 | NULL | 0 | 1 | 0 |
| DNIS Pool Endpoints |
| 314 | 1007 | sip:216.X.X.175 | NULL | 0 | 1 | 0 |
| DNIS Pool Endpoints |
| 385 | 1007 | sip:216.X.X.177:5070 | NULL | 0 | 1 | 0 |
| DNIS Pool Endpoints |
| 307 | 1007 | sip:216.X.X.146 | NULL | 1 | 1 | 0 |
| DNIS Pool Endpoints |
| 308 | 1007 | sip:216.X.X.147 | NULL | 1 | 1 | 0 |
| DNIS Pool Endpoints |
| 309 | 1007 | sip:216.X.X.170 | NULL | 1 | 1 | 0 |
| DNIS Pool Endpoints |
| 306 | 1007 | sip:216.X.X.142 | NULL | 1 | 1 | 0 |
| DNIS Pool Endpoints |
| 311 | 1007 | sip:216.X.X.172 | NULL | 1 | 1 | 0 |
| DNIS Pool Endpoints |
| 312 | 1007 | sip:216.X.X.173 | NULL | 1 | 1 | 0 |
| DNIS Pool Endpoints |
| 313 | 1007 | sip:216.X.X.174 | NULL | 1 | 1 | 0 |
| DNIS Pool Endpoints |
| 305 | 1007 | sip:216.X.X.141 | NULL | 1 | 1 | 0 |
| DNIS Pool Endpoints |
| 310 | 1007 | sip:216.X.X.171 | NULL | 1 | 1 | 0 |
| DNIS Pool Endpoints |
+-----+-------+-------------------------+--------+-------+--------+----------+-------+---------------------------------------------+
12 rows in set (0.00 sec)
This scenario occurs randomly - sometimes the desync occurs after start up, sometimes it takes a week to occur. We have some endpoints in various dispatcher groups because there is a little bit of overlap between functions of the cubes, but we didn't want to use loadbalancer module.
We're using OpenSIPS 2.1.1 on Centos 6 x86_64 . The dispatcher module parameters are default. We do set
fork=yes
children=6
And we launch opensips with -m 1024 and -M 64.
I have ruled out any interactions with mi_xmlrpc_ng commands - pcaps show no ds_set command sent during these periods where the desync occurred.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/711
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20151130/4cde95fd/attachment.htm>
More information about the Devel
mailing list