3700 Calls Stuck In Cue

[bgharddisk]

I have 3700 calls in the mySQL cue. They have been there all day with a start time of 1830. When the time came, I started getting these messages and it stopped dialing. I sent you an email with complete logs. I can't post them because of sensitive data. Does VG not support a cue this size?

 

183654.34 2 setting iDialoutReadyToDialout=1

183654.36 3 dial ado connection active

183655.38 3 dial ado connection active

183656.02 3 dial timerADOFetchComplete fired. ADO SQL query timed out. Call rsCallQueADO.Close

183656.39 4 dial ado connection active

183657.41 4 dial ado connection active

183658.42 4 dial ado connection active

183659.44 4 dial ado connection active

183700.45 4 dial ado connection active

183701.45 4 dial ado connection active

183702.47 4 dial ado connection active

183703.47 4 dial ado connection active

183704.48 4 dial ado connection active

183705.50 4 dial ado connection active

183706.03 4 dial timerADOFetchComplete fired. ADO SQL query timed out. Call rsCallQueADO.Close

183706.36 0 sys cleanup Start

183706.36 0 sys cleanup End

183707.50 1 dial ado connection active

183708.50 1 dial ado connection active

183709.52 1 dial ado connection active

183710.53 1 dial ado connection active

[SupportTeam]

Trace shows that VG is trying to make a connection to the database, but the connection does not complete and eventually VG's times out (after 10 seconds) waiting for a successful connection and aborts the attempt. It than makes another attempt (which looks like times out as well).

 

The "dial ado connection active" log entry means that VG will not make connection attempt to DB as there is an existing connection attempt outstanding.

 

The "timerADOFetchComplete fired. ADO SQL query timed out. Call rsCallQueADO.Close" is pretty self explanatory. The ADO connection attempt is aborted by calling the .Close function to the ADO layer.

 

So on this system either the ADO database connectivity, or the ODBC driver for mySQL or the mySLQ database itself is not responding.

 

If you close and restart VG do the calls get read in from mySQL, or do you see the same messages in VG's trace log again?

 

Does restarting mySQL or it's ODBC driver fix anything?

 

It's nothing to do with how many calls are loaded in the Database. VG just asks DB to give it the next call. VG does not care how many calls the database has in store. We have ran tests with hundreds of thousands of calls loaded in at once (getting close to millions actually). Size of DB does affect anything on VG's side.

[bgharddisk]

Restarting VG did not resolve the problem. I have a small window of time to get these calls out so I cleared the cue and reinserted this time with only 1000 records. It started dialing and is still dialing properly.

 

What is the query that is used to check the cue? It must select records only within the activatetime and timestart / stimstop. This query could have overtaxed the system and resulted in the error? I would think that could be it. You said on a previous post that it checks the cue every 2 seconds. There is no way that a query of that size could be run every 2 seconds.

 

Could we slow down the frequence of the cue checks to avoid this error?

 

Thanks.

[SupportTeam]

Restarting VG did not resolve the problem.

This suggests that the problem was not with the ADO layer.

 

I have a small window of time to get these calls out so I cleared the cue and reinserted this time with only 1000 records.

This by itself would not have resolved the database connection problems... the trace was showing that the database query never returned, and changing the number of records in mySQL database from 3000 to 1000 is not something that would all of a sudden make mySQL respond.

 

There is no way that a query of that size could be run every 2 seconds.

If the dialling is happening right now then you will be able to see in the trace how long the query to the database takes (it should be in fractions of a second)... Also queries can be speeded up with correct use of indexes on relevant fields (AcrivateTime, TimeStart, TimeStop, Priority and to lesser extent ID, Retries)

 

 

Frequency of checking right now is not selectable. Frequency of checking has not before been linked to errors like these.

 

Would need to see traces from when the errors started occurring to see if they show anything unusual happening on system when errors started occurring. Still - if restarting VG did not fix the problem this suggests problem was with either the mySQL database itself or with it's ODBC driver.

[bgharddisk]

Ok, thank you. I am trying to arrange paid support so I can email you the logs. I sent the request to sales@voiceguide.com. If you can tell me how much phone / email support costs, I can make payment immediately. Thanks.