Server Busy

[mserpell]

When requesting historical data, ESignal sometimes pops-up with a dialog box saying "Server Busy ......", I suspect this arises due to performance issues with my PC (currently under spec'ed) but I was wondering if it were possible to change the "time out" setting in the ESignal GUI to reduce the incidence of this problem occurring? Any help would be appreciated.

[GenSpoo]

Hi Robi,

That message pops up when you stay in an API event handler for too long. For example, put a break point in your OnBarsRecieved function and let the debugger sit there. Eventually the main eSignal app will give you that "Server Busy" message box.

Cheers... George

[mserpell]

George, thanks for the response, when you say "too long", are you able to advise how long that is and whether that time parameter can be changed?

[GenSpoo]

Sorry, I really don't have any specific info in regards to the specific timing of that message box. In general though, one should treat event handlers like interrupt handlers; get out as fast as you can. If you are doing anything other than storing the data in a buffer for later use (drawing, TA calculations, etc.), then you are in risk of getting that message. Of course, YMMV depending on how much data you are pulling down, etc.

[JimBecker17]

I get this a lot as well - and it will just sit there forever even if one continues processing the data.

As a suggestion it would be much nicer to have activity, including lack thereof, shown in the status line of the eSignal application.

This could show what it's up to without a popup coming up and needing to be dismissed.

In using the API to retrieve data oftentimes it doesn't seem anything is occurring, then after ten minutes or so a request completion comes into my app. Would be nice to at least know it's thinkin' on it!

[Guest]

First of all, there is not a status line in eSignal, other than the various colors and updates that are occuring. I think GenSpoo is on the right track with his description of the handles.

What you are asking for cannot really happen with the way the API is architected. It follows the request-response model, so when you make a request, the API will have eSignal request the data from the server farm. You may want to add timeout features to your application so you can control the flow.

I will investigate on what the error is all about.

[JimBecker17]

Hi Robi,

The status line at the bottom of the display. View->Status Bar.

Currently has things like time, connection status, # symbols.....

eSignal could show how much data has been processed from existing requests, returned back from the farm but not yet sent to the user application. Or outstanding requests pending.. percentage complete....

From what I have seen eSignal accumulates much if not all historical requests into a single return request - at least for what I'm doing. I will get 10K records in one chunk if asking for 120 days five minute - not partials. But it might be ten minutes of nothing going on while this is happening.

My app is fully asynch, and doesn't wait for eSignal. I feed out requests up to a certain number at a time, or if there have been no responses in N minutes generate more, however never wait.

Of course it is quite easy for me to show what requests are sent but not processed - it's just looking at my queue. (I also time everything, but tend to be a bit anal I guess... )

But also request responses from eSignal are quite indeterminate. Like sometimes I get a response and sometimes I don't. Ever.

Am assuming that the next release should solve some of these problems, along with the crashes. At least I'm hoping it will be better! You have all those crash reports from me!

[Guest]

Have you used Is IsHistoryReady()? It returns a TRUE when the data is ready on the server-side. The server does not sent intermitant messages.

I know that there were some issues with 7.6, but you should try using 7.7 Beta 4, which is located in the main File Share page. Make sure you uninstall 7.6 and re-reference the object. I know that it has taken care of most of the crashes that I know about.

[DionLoy]

Hi folks, the 'Server Busy' is actually a Windows-controlled dialog that pops up when it thinks that a COM/ActiveX component is taking too long processing during an event callback.

(the component in question for these cases here would be your application using the eSignal ActiveX interface).

For 7.7, I have disabled that message entirely, as some applications may want to wait on user input and not have that dialog pop up.

[mserpell]

This is good news, many thanks. I have tried to locate the 7.7 version at http://share.esignal.com/groupconten...r=&groupid=185 but I cannot find it there, are you able to post a shortcut to it's location.

Also are you able to list the improvements (ie. enhancements and bug fixes) that have been included in v7.7 in relation to the API interface.

[ACM]

mserpell
You can find 7.7 beta 4 here
Alex

[JimBecker17]

Thanks for disabling it Dion! Appreciate it.

Have not tried IsHistoryReady(), Robi. Will check into it when look at this area of code once again.

Looking forward to using 7.7 and many happy returns!

-Jim

[Guest]

I do not believe that the fix is in the 7.7 Beta 4 version. We will post a release candidate version very soon that will definitely have this message removed.

I don't have release notes available yet on all of the new features that have been added.

[LTANESIGNAL]

Don't know whether this is just me.

The previous Release Candidate actually appears to have fixed this but 7.7 Release Candidate 2 appears to have broken it again.

[Guest]

Does this problem exist in the 7.7 Final Release that was posted yesterday on our main download page?