I think your claim is rather too strong.

?

There may well be a bug as you suggest (I need to do my own test in another language to confirm it – I’m not equipped for Python), but it’s a very restricted circumstance. Your sample code is asking for delayed frozen data. Then it’s disconnecting as soon as it receives the very first price tick, without even checking what the tick type is.

?

So it’s a totally unrealistic scenario.

?

Perhaps you can narrow it down a bit more. Does it still happen if you disconnect after the second tick is received? If not, then that is useful evidence, and would be helpful to people trying to assess whether there’s a problem here that might affect them. If it does, then what about the third tick, or if you wait for say 5 millisecs, 10 millisecs, 1 second, before disconnecting? Similarly what happens if you disconnect immediately when you receive the first tick, but then delay for a short time before actually exiting?

?

I can certainly confirm that the normal usage of requesting non-delayed non-frozen data, making some sort of sensible use of the stream, and then disconnecting, works just fine with multiple clients either simultaneously or serially.

?

So as far as I’m concerned, with what you’ve said so far, there is nothing in this to prevent the vast majority of API users working with the 10.nn versions.

?

Nevertheless a bug is a bug, so it probably should be fixed assuming it can be confirmed.

?

No problems with the lengthy post, and thanks for the detail.

?

I can confirm what you’re observing, after doing some quick and not-very-carefully controlled experiments earlier this evening. Rather than write new code, I just modified the code of an existing application which allows me to specify the client id explicitly on each run. But I need to do this in a more systematic way to try and tease out the conditions that are necessary to make this happen. I know you’ve probably done all this already, but I may just come across something new that throws additional light on it.

?

I can also re-assert that my various API programs are definitely not suffering from this issue, and I’d be very surprised if any ‘normal’ API program (if there is such a thing!) were to be affected by it. My gut feel is that the early disconnection and program exit may well have something to do with it, but I certainly wouldn’t put my money on that until I’ve done more controlled testing.

?

So I’ll try to find time for some of that tomorrow morning.

?

Regarding Python, I understand exactly why it has gained so much popularity in recent times, and if I had the time to explore it I could probably find odd use cases here and there for it, but the simple fact is that I have a massive investment in .Net and VB6 (believe it or not), and to a lesser extent in Java, and Python just doesn’t fit in there (and I have zero spare time…I shouldn’t be looking at this current issue, but it’s sort of grabbed my attention).

?

Richard

?

?

I’ve managed to clarify exactly what the cause of this problem is, and it couldn’t be much simpler to describe.

?

[It’s actually very easy to demonstrate the bug using IB’s own API sample programs, and you might want to feed this back to IB (though it sounds like they’re getting a handle on it themselves). See the ‘what to do’ below.]

?

The issue occurs when the first subscriber to a specific reqMktData() stream disconnects from the API without calling cancelMktData90, and before any other client (with a different clientid) tries to request the same data.

?

It doesn’t matter how long the first stream is running for, or whether it’s in the same or a different machine than the next requester.

?

Therefore it’s vital to ALWAYS call cancelMktData() before calling disconnect(), even in error situations.

?

This explains why I haven’t had any issues with this problem in my own software: everything is always tidied up nicely before disconnecting. But now that I know this crucial fact, I’ll actually make some improvements to my code base to ensure this happens at the lowest level (there is only a single module in my platform that has any interaction with the TWS API, so there’s only one place that this needs to be done: it has a table that maintains the state of all tickers, so it’s easy to cancel them one by one).

?

Here’s what to do using the Visual Basic sample at \tws-api\samples\VB\VB_API_Sample (the Java sample works in much the same way but will need to be built first if it hasn’t been used before – actually that may be true of the Visual Basic sample too, but that’s much easier to build with Visual Studio).

?

1. Run the Visual Basic sample app TWSAPI_VBSample.exe.
2. Click the ‘Connect’ button, and fill in the connection parameters using, say, Client Id = 1.
3. When connected, click the ‘Req Mkt Data’ button.
4. In the window that opens, fill in the details for any properly-specified contract: eg symbol=IBM, sectype=STK, exchange=SMART, currency=USD, then click OK.
5. The market data should now be streaming visibly in the ‘Market and Historical Data’ panel.
6. Leave it to run for any length of time, and then click the ‘Disconnect’ button. Note that this simply calls eDisconnect() without first cancelling the market data.
7. Now repeat the sequence of steps 1 to 4 (you can either use another instance of the program, or the same one), but setting Client Id = 2. Instead of seeing the streaming market data, all that appears is the tickReqParams message.
8. Now repeat steps 1 to 4 setting Client Id = 1 again. This time the data will stream again.

?

So thanks very much for catching this, and let’s hope IB get it sorted soon.

?

Richard

?

Ok, maybe I wasn’t explicit enough.

?

The point of step 7 is to demonstrate your original observation that after the first connection is broken, another client cannot get the data for that same security. I’m sure you’re happy with that.

?

The point of step 8 is to demonstrate that even though another client (ie with a different client ID) cannot get the data, reconnecting with the original client id works, and that was also part of your original claim, so I’m sure you’ll agree with that.

?

Let’s call all this Case 1.

?

And what I didn’t say, and perhaps should have, we can call Case 2. First disconnect the clients, THEN RESTART TWS. Now repeat the sequence, but this time in step 5 click the ‘Cancel Mkt Data’ button BEFORE ?clicking ‘Disconnect’: ?then the subsequent step 7 works fine.

?

And there is also a Case 3. Here start again with a fresh instance of TWS then do steps 1 to 5 for the first client id (so don’t cancel or disconnect). Now repeat steps 1 to 5 for the second client id, and the data will stream for that one as well. If you now disconnect one or both clients without first cancelling the data, you can subsequently connect with any client id and it will work fine.

?

So in other words, with a fresh TWS instance, the first time you get market data for any particular contract you need to make sure you cancel the market data first if you disconnect before a different client requests data for that contract. Then everything works fine after that whether you cancel data before disconnecting or not.

?

The only sensible rule that ensures that everything is always ok is to always cancel market data before disconnecting.

?

I do this all day every trading day of the week: I have some clients – for example data collection programs - that make their data requests as soon as TWS starts on Sunday evening, and keep the same tickers all week (including re-establishing market data if necessary after nightly resets or other breaks in service). And I have other programs that I run on an as-required basis, using many of the same contracts, some of which I run many times a day, and I never experience the slightest problem.

?

I hope this clarifies things.

?

?

?