agents stuck in "INCALL" Autodial mode - Centos5,m

[hotdog0627]

Multi server scenario, 1 web/db server, 2-3 asterisk servers.
Centos5, MySQL5.0.22,Asterisk and astguiclient all based on latest scratch install.

the autodial campaign starts normally, places calls and connects the calls to agents. after the 1st or 2nd call that the agent has received, the calls dont get dropped after they have been disposed. leaving them "INCALL" status on the realtime screen.

When users from 2 different asterisk servers login, system runs fine for 15mins or so. but w/ users from 3 diff asterisk servers, calls dont get dropped after the first few calls.

I dont think its server load as this happens even at 1 user per server, ie 3 users on the entire system. I've a similar setup, but they use Centos4 and MySQL4.

Could it be mysql5? i just havent had the chance to downgrade it to 4 yet.

Noel

[mflorell]

I still use MySQL 4.0.X, but several of my clients use MySQL 5 with no issues, so I don't think that's your problem.

What is the loadavg when you see this happen?

what is the agiout logfile output when this happens?

[hotdog0627]

load avg is 0.02 on all servers (that's on one user per server). I will try to get some output files for you. also I noticed that when it starts to happen, the web seems to be waiting for something. its very slow...

[mflorell]

Have you looked at "show full processlist" in mysql when this happens?

Do you have skip-lookups in your startup or my.cnf for mysql?

[hotdog0627]

yes, there seems to be no connection that looks like that it is stuck. Queries seem to comein and end. Although there are some connections that are in "Sleep" status.

what do you mean by "Do you have skip-lookups in your startup or my.cnf for mysql?" I believe I dont have that in my startup or my.cnf. The only thing I added in my.cnf is max_connections=1000

What I notice is in a normal call flow, when the agent disposes the call, the connection is disconnected, or maybe after a few seconds. But in my case, the call doesnt get disconnected until the called party hangs up the phone.

[enjay]

He had stale leads stuck in vicidial_auto_calls. They were probably there when they lost power to the system.

-Art

[hotdog0627]

Hi Art,

I cleared the vicidial_auto_calls table manually, and always before I make some tests. What I cant explain is why the calls are not getting disconnected. Normally, when an agent disposes a call, the line is disconnected after a few seconds. In this case the call is still connected until the other party hangs up the phone.

[hotdog0627]

i just noticed this one: on my vicidial_auto_calls, the values on uniqueid fields have 7 decimal places

1184767882.4021398
1184767900.4021899
1184767965.4022701
1184768006.4023198


where as sql statements in FASTagiout.2007-07-18 are looking for uniqueids w/ 4 decimal places, like this:

2007-07-18 12:25:13|TEST_VDfastAGI|VD_hangup||SELECT lead_id,callerid,campaign_id,alt_dial,stage,UNIX_TIMESTAMP(call_time) FROM vicidial_auto_calls where uniqueid = '1184775764.2620' limit 1;|

Do you think this could be the problem? If it is how do I solve it?

[hotdog0627]

i think skip-name-resolve solved it.
i saw your post dated June 7.

PostPosted: Tue Mar 13, 2007 8:20 pm Post subject: Reply with quote
in your /etc/my.cnf file, add the following line after the [mysqld] section:
skip-name-resolve
Then shutdown and restart MySQL


will let you guys know if it wasnt it. thanks for your help... greatly appreciate it.
Thank you Matt for this cool program. My vicidial now is about 90 seats, doing vicidial manual mode, 30 seats per asterisk box, & 1 web/db box. Kinda pushing it to the limit... Im just waiting for extra * servers to fire it up on automode.