开云体育

I thought that I had a reliable strategy for handling disconnects, but
apparently not. After working for a month, my approach failed earlier
today. I'd like to hear how other people are doing this and/or get
feedback on my current arrangement. I'm using the Java api.

Here's what I'm currently doing:

When a EWrapper.connectionClosed() is received
- my app sleeps for 1 second.
- it thens calls ibSocket.eConnect(...), using the same client id as
the original connection; the client id is NOT zero.

In the past this has worked, but today I got the error message
Unable connect as the client id is already in use. Retry with a
unique client id
(which I believe is 326)

(I also got a
Couldn't connect to TWS. Confirm that "Enable ActiveX and Socket
Clients" is enabled on the TWS "Configure->API" menu
which I'm pretty sure is erroneous.)

I suspect that the 326 indicates that the disconnect didn't 'take'. I
thinks that this connection is between the TWS instance and my app, so I
don't know what would cause the disconnect to fail (if that's the problem).

I've considered reconnecting with a different client ID, but I think
that may cause a problem managing outstanding orders. And I believe I
read that there's a limit to how many client IDs can be active at one time.

Any suggestions would be appreciated.

thanks

I neglected to mention that I always call ibSocket.eDisconnect() before
trying to reconnnect. So the sequence I've been using after getting a
ibSocket.eDisconnect() is actually

Thread.sleep(1000L) ...
ibSocket.eDisconnect()
ibSocket = new EClientSocket(...);
ibSocket.eConnect(...);

I don't know the answer to your question. But one thing I've done that
helps me stay connected more is to set my auto logoff time to 12:55 AM
eastern time. That way if it loses connection or gets locked up
sometime after midnight and before 12:55AM, TWS shuts down, and my
program detects this and restarts and reconnects to the TWS. Not
perfect but it helps a lot. I'm of a mind to have my program
disconnect on virtually any error message from the TWS and then reconnect.

--- In TWSAPI@..., Barnet Wagman <bw@...> wrote:

I thought that I had a reliable strategy for handling disconnects, but
apparently not. After working for a month, my approach failed earlier
today. I'd like to hear how other people are doing this and/or get
feedback on my current arrangement. I'm using the Java api.

Here's what I'm currently doing:

When a EWrapper.connectionClosed() is received
- my app sleeps for 1 second.
- it thens calls ibSocket.eConnect(...), using the same client id as
the original connection; the client id is NOT zero.

In the past this has worked, but today I got the error message
Unable connect as the client id is already in use. Retry with a
unique client id
(which I believe is 326)

(I also got a
Couldn't connect to TWS. Confirm that "Enable ActiveX and Socket
Clients" is enabled on the TWS "Configure->API" menu
which I'm pretty sure is erroneous.)

I suspect that the 326 indicates that the disconnect didn't 'take'. I
thinks that this connection is between the TWS instance and my app, so I
don't know what would cause the disconnect to fail (if that's the

problem).

I've considered reconnecting with a different client ID, but I think
that may cause a problem managing outstanding orders. And I believe I
read that there's a limit to how many client IDs can be active at

one time.

Any suggestions would be appreciated.

thanks

I'm of a mind to have my program
disconnect on virtually any error message from the TWS and then reconnect.

^ Sounds like a good idea. Has anyone tried this?

I start the TWS and my "API" handler in separate threads but from the same parent. If the API handler detects a disconnect, or if it fails to receive updates on particular exchanges (i.e. futures, equities or fx) or if there are other internal failures (db or trading strategy) then I set an error status and the parent thread shutsdown and restarts the processes (TWS, API...).

This way I don't worry about whether the API detected a problem that wasn't handled properly by TWS and since TWS maintains separate connections for futures and equities it can be partially up but won't disconnect the client.

I've always found that the logic for clean startup connections is easier to handle then more complicated re-connect strategies.


Barnet Wagman <bw@...> wrote:
I neglected to mention that I always call ibSocket.eDisconnect() before
trying to reconnnect. So the sequence I've been using after getting a
ibSocket.eDisconnect() is actually

Thread.sleep(1000L) ...
ibSocket.eDisconnect()
ibSocket = new EClientSocket(...);
ibSocket.eConnect(...);




---------------------------------
YAHOO! GROUPS LINKS


Visit your group "TWSAPI" on the web.

To unsubscribe from this group, send an email to:
TWSAPI-unsubscribe@...

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


---------------------------------





---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC and save big.

Gregory Smith wrote:

I start the TWS and my "API" handler in separate threads but from the same parent. If the API handler detects a disconnect, or if it fails to receive updates on particular exchanges (i.e. futures, equities or fx) or if there are other internal failures (db or trading strategy) then I set an error status and the parent thread shutsdown and restarts the processes (TWS, API...).

Do you have a way of detecting when TWS is actually up? It seem to take
a fair amount of time (at least 10 seconds, although I've never timed
it) for TWS to fully start. I'm a little concerned about sending a
connect before TWS is available. Any idea of what happens? I.e. will
EWrapper return a recognizable error?

Also, are you using IBController to start the TWS?

Thanks

--- In TWSAPI@..., Barnet Wagman <bw@...> wrote:

Do you have a way of detecting when TWS is actually up? It seem to take
a fair amount of time (at least 10 seconds, although I've never timed
it) for TWS to fully start. I'm a little concerned about sending a
connect before TWS is available. Any idea of what happens? I.e. will
EWrapper return a recognizable error?

If you look at the source for EClientSocket.eConnect(), you will see that it generates an error 502 (Couldn't connect to TWS. Confirm that "Enable ActiveX and Socket Clients" is enabled on the TWS "Configure->API" menu.) if any exceptions are thrown while attempting to connect to TWS.

I've not found a definitive way of knowing when TWS has completed startup so I too sleep though for an initial 20 seconds. I then attempt connects from my API handler using eConnect(host, port, clientid).. and if it is successful then a call to isConnected() returns true...otherwise I sleep for 2 additional seconds and attempt another connection. This will repeat itself up to10 times where if it has continued to fail I reset the applications and start over from the beginning.

I do not use IBController though I would think that it would be similar starting it in it's own thread like I do with jclient.


Barnet Wagman <bw@...> wrote:
Gregory Smith wrote:

I start the TWS and my "API" handler in separate threads but from the same parent. If the API handler detects a disconnect, or if it fails to receive updates on particular exchanges (i.e. futures, equities or fx) or if there are other internal failures (db or trading strategy) then I set an error status and the parent thread shutsdown and restarts the processes (TWS, API...).

Do you have a way of detecting when TWS is actually up? It seem to take
a fair amount of time (at least 10 seconds, although I've never timed
it) for TWS to fully start. I'm a little concerned about sending a
connect before TWS is available. Any idea of what happens? I.e. will
EWrapper return a recognizable error?

Also, are you using IBController to start the TWS?

Thanks



SPONSORED LINKS
Investment management software Investment property software Investment software Investment tracking software Return on investment software Stock investment software

---------------------------------
YAHOO! GROUPS LINKS


Visit your group "TWSAPI" on the web.

To unsubscribe from this group, send an email to:
TWSAPI-unsubscribe@...

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


---------------------------------





---------------------------------
How low will we go? Check out Yahoo! Messenger’s low PC-to-Phone call rates.

--- In TWSAPI@..., Barnet Wagman <bw@...> wrote:

Here's what I'm currently doing:

When a EWrapper.connectionClosed() is received
- my app sleeps for 1 second.
- it thens calls ibSocket.eConnect(...), using the same client id as
the original connection; the client id is NOT zero.

Do you have any idea why EWrapper.connectionClosed() being called at
all? In the vast majority of cases the TWS / API connection is a local
socket connection which should be 100% reliable. If you read the source
for EReader, the only time that the connection is closed is when your
code throws an exception while processing a message. (The only other
call is EClientSocket.close()). That being said, I have seen cases where
a disconnect can cause TWS itself to throw an exception. The log file
will contain a stack trace that may help.

Do you have any idea why EWrapper.connectionClosed() being called at
all? In the vast majority of cases the TWS / API connection is a local
socket connection which should be 100% reliable. If you read the source
for EReader, the only time that the connection is closed is when your
code throws an exception while processing a message. (The only other
call is EClientSocket.close()). That being said, I have seen cases where
a disconnect can cause TWS itself to throw an exception. The log file
will contain a stack trace that may help.

^ I was under the impression that if the connection between IB's server
and TWS is broken, the TWS <-> api connection is also broken, but I
could be wrong about that. I see what you mean about EReader; are you
sure that nothing in processMsgs() itself (as opposed to the eWrapper
calls) can throw an exception? I'm pretty sure that my code isn't
throwing anything, but I'll check again. In my case, the TWS/API
connection is local, so I would expect it to have any problems.

I posted my ATS code at

It has been working for me for over 7 months, handles temporary
disconnects okay. It might give you some ideas.

The only thing that has changed is the way I handle an 1101 error:

else if(errorCode == 1101)
{ log("errorCode == 1101");
/*m_client.cancelMktData(contract.getContractID()); //
vszmyd 20060319
sleep(2);
contract.m_contractID += 1000;
m_client.reqMktData(contract.getContractID(), contract);*/
reConnect();
}

I did not get an 1101 error often enough to really test it out. It
seemed safer to just reConnect().

Note that if you try to call eDisconnect() on a connection that has
already been disconnected it will throw an error, I believe 526.

Any feedback on the code, good or bad, is welcome.

Vic

--- In TWSAPI@..., Barnet Wagman <bw@...> wrote:

I thought that I had a reliable strategy for handling disconnects, but
apparently not. After working for a month, my approach failed earlier
today. I'd like to hear how other people are doing this and/or get
feedback on my current arrangement. I'm using the Java api.

Here's what I'm currently doing:

When a EWrapper.connectionClosed() is received
- my app sleeps for 1 second.
- it thens calls ibSocket.eConnect(...), using the same client id as
the original connection; the client id is NOT zero.

In the past this has worked, but today I got the error message
Unable connect as the client id is already in use. Retry with a
unique client id
(which I believe is 326)

(I also got a
Couldn't connect to TWS. Confirm that "Enable ActiveX and Socket
Clients" is enabled on the TWS "Configure->API" menu
which I'm pretty sure is erroneous.)

I suspect that the 326 indicates that the disconnect didn't 'take'. I
thinks that this connection is between the TWS instance and my app, so I
don't know what would cause the disconnect to fail (if that's the

problem).

I've considered reconnecting with a different client ID, but I think
that may cause a problem managing outstanding orders. And I believe I
read that there's a limit to how many client IDs can be active at

one time.

Any suggestions would be appreciated.

thanks

--- In TWSAPI@..., Barnet Wagman <bw@...> wrote:

I thought that I had a reliable strategy for handling disconnects,

but

apparently not. After working for a month, my approach failed

earlier

today. I'd like to hear how other people are doing this and/or get
feedback on my current arrangement. I'm using the Java api.

If it is any consolation, IB had major problems today. Accounts were
continually being logged out and back in for at least a few hours. It
was certainly a good test case for reconnection logic. Anyway, have
you tested the reconnect logic by pulling your ethernet cable to
simulate a log out?

Hi,?tripack44,

Can you explain how to do it more details? I am confused in this in python,Many thanks.

TWS shuts down, and my
program detects this and restarts and reconnects to the TWS

--


------
Forex trader
David Liao

Hi,Gregory Smith,

Sounds great.Can you explain more about how to do it? I am confused about this in python,Many thanks.

Hey David -- this thread is from 2006 so you might not get a useful response.

Perhaps? ? is worth reading.

This ruby code handles the reconnection feature

```
# Handy method to ensure that a connection is established and active.
#
# The connection is resetted on the IB-side at least once a day. Then the
# IB-Ruby-Connection has to be reestablished, too.
#
# check_connection reconnects if necessary and returns false if the connection is lost.
#
# It delays the process by 6 ms (150 MBit Cable connection)
#
#? a =? Time.now; G.check_connection; b= Time.now ;b-a
#?? => 0.00066005
#
?? ?def check_connection
?? ???? ??? ??? answer = nil; count=0
?? ???? ??? ??? z= tws.subscribe( :CurrentTime ) { answer = true }
?? ???? ??? ??? while (answer.nil?)
?? ???? ??? ??? ??? begin
?? ???? ??? ??? ??? ??? tws.send_message(:RequestCurrentTime)??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? ??? # 10 ms? ##
?? ???? ??? ??? ??? ??? i=0; loop{ break if answer || i > 40; i+=1; sleep 0.0001}
?? ???? ??? ??? ??? rescue IOError, Errno::ECONNREFUSED?? # connection lost
?? ???? ??? ??? ??? ??? count = 6
?? ???? ??? ??? ??? rescue IB::Error # not connected
?? ???? ??? ??? ??? ??? reconnect
?? ???? ??? ??? ??? ??? count +=1
?? ???? ??? ??? ??? ??? sleep 1
?? ???? ??? ??? ??? ??? retry if count <= 5
?? ???? ??? ??? ??? end
?? ???? ??? ??? ??? count +=1
?? ???? ??? ??? ??? break if count > 5
?? ???? ??? ??? end
?? ???? ??? ??? tws.unsubscribe z
?? ???? ??? count < 5? && answer #? return value
?? ?end

```

You might translate this to your favorite language.