MT4 datastream freeze
Yes... That looks like the problem I also have... thanks for the hint.
These might help...
This logs connection irrespective of ticks by looping in init.
And I found this thread useful
https://www.mql5.com/en/forum/126166
Hope that helps
V
These might help...
This logs connection irrespective of ticks by looping in init.
And I found this thread useful
https://www.mql5.com/en/forum/126166
Hope that helps
V
Well, this was all I needed... "eliteeservices" posted a piece of code which broke the ice and turned on the "lights"...
void CloseTerminal() {
int hwnd=WindowHandle(Symbol(),Period());
int hwnd_parent=0;
//----eesfx.com
while(!IsStopped())
{
hwnd=GetParent(hwnd);
if(hwnd==0) break;
hwnd_parent=hwnd;
}
if(hwnd_parent!=0)
PostMessageA(hwnd_parent,WM_CLOSE,0,0);
//----eesfx.com
return(0);
}
Using this I will write the proofing package. As a payback I will post the package with full instructions after testing and making sure it works properly.
Thanks guys for putting me on the right track... I will probably need a week to code and livetest it properly, but I'll post it back if successful. Finally I'll be able to sleep well. Thanks again :-)))))
Yeah, I liked that code too. The fly in the ointment is that upon terminal restart no EA's initiate until connection is established, so if you restart and fail to connect no code will run to test connection so you get stuck. (or i'm stuck anyway). If you solve that one and share it, you will be my hero :).
What about duplicating your MT4 installation, call it primary and secondary, identical in every way except their install paths (naturally)...say you are currently operating on the "primary" instance and your connection detection determines a restart is needed.
Rather than restarting itself and risking a no-connect situation you instead have it startup the secondary instance (copying all the requisite up-to-date persistance layer info first) and then it sleeps. (naturally you'd have a globalvariable that tells all EA's to do nothing in the event that the connection in primary is restablished in the meantime)
Periodically it checks the secondary install path for a "I'm alive" file that is only created in the event that the secondary instance did come up and a connection was made.
Then the primary deletes the "I'm alive file" and shuts down. In the event that the secondary instance fails to establish a connection after a perdefined grace period you could invest some efforts towards capturing the PID of the secondary instance and kill it programmatically, then attempt a restart.
The secondary MT4 instance would likewise be setup to restart the primary MT4 instance in the event that it's connection is dropped. So they ping-pong back and forth as needed but the handshake of confirmed connectivity is required before the initiating instance kills itself.
That is certainly worthy of investigation. Thanks for the idea. It's going to need some thought and careful programming to make sure I don't end up with two instances of an EA trading. An I'm alive file which initiates a shutdown of primary and a test for the alive file to keep shuting down and restarting until secondary reports alive. I persist global variables to file anyway on external HDD in the event of PC complete implosion...or theft so getting a second instalation to pick up where primary left off shouldn't be too much drama.. real food for thought. Thanks
V
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Hi,
I've been searching this forum for the problem, but it seems there's no real solution for this issue...
I have a live and numerous demo accounts at MIG. Very frequently, mostly during the nights, it happens that the datastream just stops. The connection on the terminal is indicated to be active, only no ticks are arriving and the chart is "frozen" at 03:00 AM or whenever the datastream stopped.
Now as far as I understand, there's simply no way to diagnose this condition from within an EA, because any checks I write into the expert would only be triggered if there's tickdata... And since the main problem is actually the absence of any data despite of a pseudo-active connection, the checks in the expert would then never be triggered.
For those of you who are wondering, I have dedicated servers placed in datacenters (2 separate hosting companies with good names), so Internet connection should not be an issue. None of the other brokers' demos are experiencing the same problem on those servers, only MIG. But MIG insists that they have no problem... So here we are...
Anyway... Back to the topic. Since not only the demo, but also the LIVE account's datafeed is freezing during nights, I'm very concerned now that such an issue, if left unresolved, will result in big losses of money or worse.
Do any of you have any idea on how to, maybe externally, detect such a connection failure/freeze and reinitiate the connection?
My idea was the following:
1) Write into a small text file the date of the last action on behalf of the EA.
2) A complex shell script or a C++ application more likely, will monitor this file, and if the activity is less than "X" minutes, it will kill the live terminal, and restart it, based on the PID.
3) After this, the watcher script backs off for five minutes to give time for things to consolidate.
4) Iterate from step 1...
The biggest problem for me with this approach is how to determine what is the optimal value for "X"? I mean, when, or rather, after how many minutes of tick-inactivity can we comfortably say that a connection is "dead"? What do you think? And this also brings up another question: Monitoring tick data on a single pair is one thing. But what if that pair "legitimately" doesn't move for an hour or more hours? Because it can happen... Then what? How do I tell that the connection is still alive? Should I monitor multiple connections? In that case, how many pairs should I monitor to be consistent?
Another approach would be to use a dump application on the TCP layer level to watch the datastream of the trading station's process for activity. If there's no TCP protocal data activity for X minutes, then the connection is probably dead. This is a more sophisticated approach, but I'm not yet sure wether connection-based "jitter" or retries, etc would effect the alerting performance of this... But theoretically it could be done...
Anyone has a better ideas or, experience with this?
Thanks for any hint... This is a big issue...