开云体育

Hi there,

I am a newbie struggling with the reconnection of my python script after tws auto restarts (or manual restart for that matter). I know similar questions have been asked before and I am trying to follow this advice?to use connectionClosed callback but cant really seem to get it working.?

my callback function:

def connectionClosed(self):
    print('connection lost')
    while self.isConnected() is False:
        print('trying reconnection')
        self.connect('127.0.0.1', 7497, 123)
        time.sleep(30)
 
    return

But it doesn't work. apparently the following error
AttributeError: 'NoneType' object has no attribute 'settimeout' occurs at line self.connect('127.0.0.1', 7497, 123) .

Quite desperate to get it working. Any help would be extremely appreciated!

?

I don't use python, but if I get a disconnect (isConnected = false, or any of the other connection error codes) I execute a "disconnection" method, a 1 minute pause, and then a full "reconnection" method.?

and in disconnection method you just call the api's app.disconnect() method?

and in "reconnection" method do you simply call the api's connect(host, port, clientId) method or do you something else as well?

bump this thread

facing the same issue with settimeout

the thing is the logic isConnected() ? > disconnect() > connect() is flawed by design, as the thread running the connection will terminate as it disconnects
therefore a new thread needs to be created again for every re-connection, and all the objects in memory on the previous thread need to be transferred or lost

Not sure that there is anything wrong with the connect/disconnect API design. Works well for many of us (and for some of us for decades).

Also, not sure what objects of the previous reader thread need to be transported. The reader thread (I guess that is the one you are taking about) has only one purpose and contains no long-term state:

• It reads a stream of bytes from the network socket that connects the client with TWS/IBGW, assembles complete API messages, deserializes the messages into objects, and calls the corresponding EWrapper callback with those objects

• It maintains no state and becomes obsolete as soon as the network socket connection is closed

When your client is not connected yet (504) or an existing connection with TWS/IBGW is lost (502), no network socket exists and there is no need for a reader thread. When a new network connection exists upon a successful connect() , a new reader thread is created to process the messages as long as that socket exists.

At any point in time, your client may voluntarily call disconnect()/connect() or, upon receiving an error 502, call connect() to reestablish the connection.

In the architecture of your application stack, TWS API is way at the bottom as an "Adapter" with a very simple interface contract:

• It can create a connection with TWS/IBGW
• While connected, it forwards requests your client makes via the EClient interface to TWS/IBGW
• While connected it forwards responses from TWS/IBGW to your client via the EWrapper interface
• It informs your client when the network connection with TWS/IBGW is lost (when TWS/IBGW voluntarily closes the connection or when it is closed by your network)

• It allows your client to disconnect voluntarily from TWS/IBGW

As an "Adapter" TWS API's life-cycle starts with connect() and ends with disconnect() or error 502. The API plays no role and is not involved in maintaining or restoring application state between connections. Higher layers in your application stack architecture or framework need to provide any "high availability" functions so that disconnect/connect cycles are hidden from the business logic in your client application

• Upon (re-)connect(), your framework will generally request all positions and open orders on behalf of your business logic.
• Upon (re-)connect(), your framework will generally subscribe to all data feeds the business logic needs

• Your framework completely hides API internal concepts (such as requestIds) from the business logic layer. That is often done with software patterns such as "model-view-controller" where the "model" buffers and separates the world of your business logic from the world of TWS API connections

闯ü谤驳别苍