Voiceguide Crashing Under Heavy Load

[Guest Jonah]

I have 24 lines running and they all seem to run fine for a few hours until all of a sudden the entire system crashes. I am using WCF to monitor the lines as well as running an external program. I will try to send logs to support as they are too big to attach here (76mg). I don't know the exact time of the crash but I believe it was around 5PM.

[SupportTeam]

Please .ZIP up the logs and make them available for download if they are too big to attach to an email when ZIPed.

 

Are there any error messages in the Windows' System Event Log?

[SupportTeam]

as well as running an external program

Is this system still setup in the way that your WCF app is used to essentially directly call Dialogic API?

 

Last time we had a report of a v7 crash was also from your system, and we advised that the problem was in way that WCF was used to call the Dialogic API in such a way that it resulted in a Dialogic drivers eventually crashing. Here is link to that topic:

 

http://voiceguide.com/forums/index.php?showtopic=6192&view=findpost&p=28007

 

Is this system still setup in same way?

[Guest Jonah]

I am only using WCF to MONITOR the events triggered by voiceguide. I am using some of the Voiceguide API calls to play voice files and set variables through a .NET exe application. It seems to be a very rare occurance when it does crash. It made over 10k calls yesterday without crashing but occasionally something does trigger the crash. I am modifying the code to check that the line is in a "Connected" state before calling the VoiceGuide.playstart function. We'll see if that takes care of it. I'll get back to you if the problem continues.

 

Thanks!

[SupportTeam]

I am using some of the Voiceguide API calls to play voice files and set variables through a .NET exe application.

That would be using the PlayStart etc calls through WCF API, right? This is exactly the action that was identified as the cause of Dialogic drivers being put in error state before in this topic: http://voiceguide.com/forums/index.php?showtopic=6192&view=findpost&p=28007

 

If you encounter a crash situation again please post the last vgEngine log file (unzipped vgEngine trace is max 10MB, less when .ZIPed) and the last couple of hours of the ktTel trace, as well as the transcript of the error in the Event Log viewer or the DrWatson report.

 

To split large ktTel files use something like this: http://www.softpedia.com/get/System/File-Management/Text-File-Splitter.shtml

[Guest Jonah]

It ran fine for about 3 days straight (20k calls or so). Then it crashed yesterday morning pretty much right when I started calling (at 9 AM) and again this morning at about 9:15 AM. I will attach the log files that I have - although I disabled logging because it was using up all of the HD space on the C drive so I'm not sure if there is anything there that will help you. I have also attached the System Error screen print. Let me know if there is a way I can turn on logging just to watch for this stuff without creating large log files.

 

P.S. I did add a check to make sure that the call was in a "CONNECTED" state before calling the playstart function.

 

Thanks!

Error.doc

1201_0900_vgEngine.zip

[SupportTeam]

This error has exactly the same fault address as in the previous case that we mentioned in our initial reply.

 

So most likely it is exatly the same problem, in which case our answer from last problem report would apply ( http://voiceguide.com/forums/index.php?showtopic=6192&view=findpost&p=28007 ).

here is the relevant part of that previous reply:

the external app is not waiting for Human/Machine detection to complete before starting the play - but this free support forum is not really intended to provide support in debugging user's own external applications. If you chose to use COM/WCF to call Dialogic APIs directly then please contact sales@voiceguide.com to setup a support agreement that will allow us to handle support enquiries related to this system in future.

 

NB. The vgEngine traces posted also shows a lot of errors with WCF layer reporting not being able to communicate to your application(s)..

We woudl advise to design external applications in such a way that the WCF layer does not encounter such errors on a continous basis.