I find that if I instantiate multiple worker threads with the intent of pulling contract details on several contracts concurrently, even though I can submit multiple requests instantly, I only receive one symbol at a time in the same order that the requests were sent. For example, if I request option contract details on IBM, AMZN, and FB, I can make those requests nearly instantly and then I'll get many callbacks returning data for IBM, then AMZN, and then FB. If the service was truly concurrent, I would expect to see the callbacks mixed instead of receiving callbacks for one request at a time. Has anyone managed to pull contract details concurrently through IB Java API? The API is obviously geared for concurrency, but not sure if that applies to requesting contract details.
It doesn't matter if it's Java or C++, all the messaging in the API is piped through 1 thread. The only way to get that kind of parallelism is through multiple connection instances. I've never done that before so I don't know if it would work. They may have additional throttling.
I think you can have max 8 connections to TWS. I connect from multiple processes, but multi threading should work as well. If i recall correctly there are restrictions like if you create an order you can only modify from a connection with the same connection id as was used to create..
Well at some level it has to be concurrent for real time data. Doubt they would intend for the client to only watch one contract or stock at a time. But for pulling contract details, it seems that it might not be. I agree that it probably has nothing to do with the language. It's just socket programming. Just curious if anyone else has noticed that restriction.
I'm updating my puller to cache the contract details so I only have to pull them once a week or less often than that. When are new option chains typically added? Aside from very liquid products that offer daily options such as SPY, I assume that they are are only added once per week. What day is that typically?
Do you send all your requests through one socket client? Or do you use one socket client per request? If you use one socket client then I can imagine that this can be a cause for serialisation.
Yes, I only instantiate one socket shared among all the threads. That shouldn't be the bottleneck though because I can receive the bid/ask for strikes, deltas, and historical bars concurrently. But you're right. I could allocate a new socket client for each puller. What's the maximum number of connections allowed?
A better question here might be: what's wrong even if you are being serialized here? Meaning: why do you need high concurrency for something like contract details? Are you pulling a large number of them that this is becoming an issue or is this really just a "nice to have" thing?
I don't actually need it. It's just a nice to have. It means that I don't have to wait as long to get my data. But since I do all my analysis after market close, it doesn't matter too much. The need is also reduced further since I started caching the contract details and only need to pull it maybe once a week.