Closed xerges-crypto closed 2 years ago
rlktradewright
commented
3 years ago You should configure the settings you require in TWS manually. You only need to do it once.
It is not IBC's function to be a general-purpose TWS configuration mechanism. There are simply too many settings.
xerges-crypto
commented
3 years ago You should configure the settings you require in TWS manually. You only need to do it once.
Your are right If we choose to store setting in server side, so this setting and others will be preserved for next relaunch of TWS/GW.
It is not IBC's function to be a general-purpose TWS configuration mechanism. There are simply too many settings.
Ok, Maybe I miss the point. I guess using TWS controlled by a supervisor (like IBC) was primary intended for algorithmic trading, so I was surprised this setting was missing, mainly because the code looks like it was the intention in some point in the past.
Finally, using TWS with containers suggest the container itself should be disposable and can restart a fresh new one in some other point in the infrastructure asap, so all needed parameters would be set when the docker will respawn, or configured at docker building/starting time.
I think others users will found useful to have the Socket API option and continue using IBC.
At this point I have some solutions:
useRemoteSettings=false in jts.ini and update file before launching TWS.Option 2 works but the only thing I would miss is the ability of controlling when an existing session is detect (ExistingSessionDetectedAction IBC's parameter) but on the other hand is faster and less resource consuming.
Thanks for your time.
xerges-crypto
commented
3 years ago Dear Richard,
I have found that you try to set this configuration when you try to set the ApiPort, that have sense, but ONLY try to activate the ""Enable ActiveX and Socket Clients"" check-button when TWS (server config) and IBC config don't match.
Maybe you may consider to try to set this check-button every time a port is specified or designed by a new option in ibc.ini
Best regards.
rlktradewright
commented
3 years ago You don't need to 'store settings on server' for the settings to be preserved between sessions. The local tws.xml file always contains the current settings: storing on the server simply uploads this file to the IB account server when TWS exits.
The primary purpose of IBC is to automate various things that are inconvenient for a user who is not sitting in front of a TWS display, in other words to get TWS up and running and deal with various conditions with no user intervention. Whether the user is running an automated trading system is of no concern to IBC.
I run an automated system using IBC all day every trading day. There is nothing in IBC that prevents me doing that. I configured TWS in the way I need it years ago, and only very rarely have to change anything manually: usually because I need to connect a client program from a DHCP device that is not currently in the Trusted IPs list.
If you want to run it in Docker, you need to make provision in the Docker build to include the pre-configured TWS settings in the image, as you have observed in your post. If you want any changes in TWS during the Docker session to be preserved across Docker instantiations, then you'll need to make sure that the TWS settings directory is on some sort of persistent storage such as a bind- or volume-mount If you also store settings on the server, then any changes made during the TWS session in Docker - such as adding market data lines or charts - will be restored if you subsequently need to run TWS locally to create a new baseline configuration .
Why do you think that running in Docker prevents the use of ExistingSessionDetectedAction? It makes no difference to IBC whether it is running on a physical machine, in a virtual machine, or in Docker - if TWS displays the Existing Session Detected dialog, IBC will respond to it in accordance with the ExistingSessionDetectedAction setting.
I'm not going to change the way the OverrideTwsApiPort setting is implemented: it's called 'override' rather than 'set' because it's based on the assumption that you already have a properly configured and working TWS but (for some reason) you want to use a different API port for the current session.
rlktradewright
commented
2 years ago Closed due to lack of further input.
grantrosse
commented
11 months ago "If you want to run it in Docker, you need to make provision in the Docker build to include the pre-configured TWS settings in the image, as you have observed in your post. If you want any changes in TWS during the Docker session to be preserved across Docker instantiations, then you'll need to make sure that the TWS settings directory is on some sort of persistent storage such as a bind- or volume-mount If you also store settings on the server, then any changes made during the TWS session in Docker - such as adding market data lines or charts - will be restored if you subsequently need to run TWS locally to create a new baseline configuration." ^saved me, but I had to figure out which is the settings folder. Come to find out it's defined in the /root/Jts/jts.ini file.
paying it forward- here is the docker command I'm running: sudo docker run -d -v /ibc/ccgpgldepbhgmoncipijhphmkiaclafiofagjeaj:/root/Jts/ccgpgldepbhgmoncipijhphmkiaclafiofagjeaj:rw --restart unless-stopped -p 8080:8080 -p 5900:5900 -p 80:80 -p 7497:7497 tws
rlktradewright
commented
11 months ago @grantrosse
You need to be a bit careful here.
jts.ini doesn't always contain this information. For example if you shut down TWS/Gateway, then delete jts.ini and run IBC again, it will all work perfectly, and the newly created jts.ini won't contain it. I don't know offhand at what point TWS updates jts.ini to include it.
grantrosse
commented
11 months ago @rlktradewright understood- thanks for the heads up- will keep in mind if we try to automate grabbing the settings folder.
Dear Richard,
I was forced to use the latest version (984) standalone installer due long user names seems to disable "Login" button and TWs/GW doesn't login.
I manage to launch ''ibcstart.sh'' with this version to start TWS and everything seems to work fine, but I notice that checking "Enable ActiveX and Sockets Clients" is likely skipped somehow.
I notice that there is a
EnableApiTaskclass designed for that, but I can not see in the log any activity, but others likeConfigureReadOnlyApiTaskdo their work with these settings.I know that GW has no problem as this flag is missing (and set by default), but I would like to use TWS for manage the position in case anything is going wrong.
Do you mind to give any hint for solving this issue please?
Please, let me know anything from my side that I can do for helping in the solution.
Thanks in advance,
Trace: