Automation Error: System Call Failed

[chrisjames]

Now that the out of synch/duplication issues with TSales data have been resolved i find I have a odd and surprising problem using the Desk API and pulling real time TSales data...

Goal...
Using the mutiple handle method: To pull TSales data for 30 stocks (Dow Index) in real time - ONLY trades - NO quotes - and insert the ts data into an SQL server db.

(Filtering out quotes and receiving only trades in the handles cuts out a lot of ts data records)

My HardWare...
P3 / 750mhz with 1Gig Ram - Win2000 os with latest service paks

Result:
With this PC I can successsfully and accurately pull TSales trade only data (30 stocks) with no problem during the slow parts of the day. During the first 1 and half hours of the opening and the last 2 hours of the close i get mutiple repeats of this error:

Automation Error: System Call Failed

where my CPU goes to %100 for a 3 or four minutes and then this error happens. I code my app so that it automatically restarts winsig.exe and starts downloading the TSales for these 30 stocks within seconds so i am back up but i am having about 35 to 45 crash errors like this a day... overall i add up that i am losing 60 minutes of data a day for these 30 stocks - a significant amount... i am not trying to pull 300, or 150 or 75 - just 30 stocks... that's all...

so... i think - well of course i just need more CPU power since i am a little out of date as far as clock speed and mhz goes right...

so using my partners P4 / 2.8 system with
and a fast dsl line and with plenty of ram (512mb)... no Hyperthreading

and we crash (get the Automation Error) MORE !!...

so then i decide ok... lets go to the big mama... i have access to a Windows 2003 server with 2 Xeon 2.8 ghz Processors each having Hyperthreading turned on and a Gig of ram on a fast Biz Dsl line... which gives up 2 physical processors and 2 logical processors (4 total) so i run my app and FIND I CRASH MORE (auto error again - only error)...

crash crash crash ... AND THE CPU USAGE ON THE DUAL XEON SYSTEM NEVER WENT PAST 40% if it ever even got that high - ...

this was at 11:50am pst... so after a number of crashes on the powerful server that happend every two minutes i went back to my P3 / 750 and ran my app for about 20 minutes without a problem although again it crashed a number of times a little later going into the close

so what tha???

Jim Becker17 has some ideas about this but i will let him post if he would like...

Chris James...

[JimBecker17]

Well since Chris called me out by name guess I better say something.

Yes, there is at least one unresolved bug with eSignal which causes it to crash. So far this morning I've probably had twenty crashes from this.....

This is not a new bug, it has been around for at least a few months - 7.6 had it as well as what is currently released.

My code both restarts eSignal on crashes, but also I have a separate thread looking for the "CoreReport" application which comes up on crashes. I kill that off and restart as well, which prevents the system from blocking if I'm not there to interact. So it just crashed as I was typing, but it will reset here shortly w/o me having to click on anything.

The crashing I'm getting is NOT from T&S interaction, my hunch is it is from RequestHistory. Since it happens more on Mondays it's possible bad data from the eSignal servers (when taxed) might be prompting it..

Ok, the GOOD news is that this time last week wrote a sample app and sent it to Robi and have PMed Simon that this was done as well. This app just does the same set of actions over and over with eSignal, changing symbols. But it keeps 40 parallel connections, so that makes it a bit pushy. Nothing fancy, but something that should run OVERNIGHT if eSignal is clean.

So if the eSignal development side uses BoundsChecker, or just the debug environment for development, and run this app they would probably find what is running into the weeds pretty quick.

Chris and I are using the product in a non-interactive sense, so we are bringing existing problems to the surface which would not be seen by regular users often enough to be easily repeatable.

Chris and I have talked on the phone about this a bit, his faster system just probably causes the asynchonous combo of events that much quicker and crashes quicker. Some memory is probably getting smashed then sometime later we crash. To me it looks like someone is referencing off a null pointer, but I'm really good at guessing wrong..

Any feedback from Robi or Simon either on the forum or via email or PM would be nice at some point. Didn't really want to bring out a lotta dirty laundry, but with a repeatable test app should be easy to track down and squash this bug. Thx.

-Jim

[Guest]

I have your application and will try to get this resolved by the 7.8 release of eSignal. This version has a very short cycle, as most of the new features deal with new exchanges and there are not many GUI enhancements.

Our developers are away for the next few weeks, so it'll be a while before I can report progress on this specific issue.

Thanks again for the sample - it makes the resolution of the problem a whole lot easier.