gnzsnz
commented
7 months ago hi,
based on what i can see on the log, it seems that
- ib gateway is running, or was running until at 01:00:09, at 01:57:50
- socat is running, the error is coming from socat. socat is receiving messages forwarding it to port 4001, but is not getting a reply. so it's not due to "Forking :::4001..."
- if socat is working, then the issue is on 127.0.0.1:4001 which is the ibgateway port listening on localhost. so ibgateway is not listening. why? i don't know there is nothing on the log to diagnose that.
- data connection between ibgateway and IBKR seems to be OK. it would be in the logs if it's not.
what could be the cause, well i don't know much details, but i would start looking at
- how are you doing the heartbeat? are you requesting bars periodically?
The advantage of reqRealTimeBars is that it behaves more robust when the connection to the IB server farms is interrupted. After the connection is restored, the bars from during the network outage will be backfilled and the live bars will resume.
reqHistoricalData + keepUpToDate will, at the moment of writing, leave the whole API inoperable after a network interruption.- are you using async?
The One Rule:
While some of the request methods are blocking from the perspective of the user, the framework will still keep spinning in the background and handle all messages received from TWS/IBG. It is important to not block the framework from doing its work. If, for example, the user code spends much time in a calculation, or uses time.sleep() with a long delay, the framework will stop spinning, messages accumulate and things may go awry.
The one rule when working with the IB class is therefore that user code may not block for too long.hope it helps
peebeejay
Describe the bug
Once again, thank you for all the fantastic work on this docker image!
I have a container running the
ib-gateway-dockerimage that has been running for a few days. The daily restart occurs at1AM, and last night, around 1 hour after the restart, a set of errors began to appear, which I can't seem to properly understand. Essentially, what I'd like to figure out is the cause of the issue, and whether the issue is solvable here at the container level, or somewhere deeper in the stack, such as with IBC. Any help would be much appreciated!Is the issue caused by not waiting for the
Forking :::4001 onto 0.0.0.0:4003 > trading mode liveline to appear?Ostensibly, the error message was triggered by a 1-min heartbeat related request that I use for uptime monitoring. The python on the client side that makes this request looks something like this:
The logs from the docker container look something like this:
To Reproduce
docker runcommand:docker compose updocker-compose.ymldocker compose configExpected
I expect these errors to not occur and for the connection to be more stable. Perhaps also expect that the logs say more about this particular issue.
Container logs
See above
Versions
Please complete the following information:
Ubuntu 20.04.6 LTSDocker version 24.0.5, build 24.0.5-0ubuntu1~20.04.1docker image inspect ghcr.io/gnzsnz/ib-gateway:tag):stabledocker images --digests):sha256:5b45bc84ad3e2ff363723592cb5df118d17ace67dcb676ffc6a3a9405da08968