any IB java api experts? code question

Discussion in 'Automated Trading' started by newguy05, May 6, 2009.

  1. in IB java api, you overwrite the tickPrice() function as entry to your blackbox. Each time a new tick price comes in, tickPrice() is called.

    public void tickPrice(int tickerId, int field, double price,int canAutoExecute )

    IB is down for the night so i cant test, but i am assuming tickPrice() is asynchronous. This is fine most times as call_my_blackbox will finish processing the tick price before the next tick price comes.

    But in fast moving markets, if the next tick price comes in before the previous one is processed by call_my_blackbox(price), you are going to run into the classic data corruption problem with threading.

    I am curious how everyone deals with this problem, do you synchronize call_my_blackbox(price). That cant be the solution because it will just backup the tick price and make your system lag behind real time.

    The other solution is if the blackbox is still processing, to skip the next tick price completely, and keep skipping until call_my_blackbox finishes processing, but that will mean the next tick price data could be a big jump from previous one, throwing off the system.

    Any coders here who can offer some insight on dealing with this particular issue.
  2. gkishot


    As far as I know the minimum interval between tickPrice() calls is 5 sec. So even in the fast moving market there is a lag of 5 sec to finish your processing.
  3. maxdama


    Good question
  4. the call of tickPrice specifically is actually sychronous, otherwise the function signature would look different.

    there is some threading that occurs in terms of received ticks come in via a tcp socket and are communicated to the api via windows messages (this is on windows, after messages come out of the sockets may differ slightly on linux). however they are processed sychronously at this point on a single thread.

    although in practice this does not really matter, because IB regulates the flow of ticks and only sends one every 200ms (5 per second) per symbol, and caps the total number of symbols you can request at once. this is exactly to save programmers from having to worry about threading and also to protect their servers from boxes that don't process ticks fast enough.
  5. 'the minimum interval of 5 seconds'

    this is not correct... otherwise you could only get updates every 5 seconds, which is not what happens.

    i believe he's referring to being able to have 5 updates per second like I mentioned in my above post.
  6. IB/TWS is available all night. IB only shuts down TWS access from Friday midnight until noon on Sunday.

    IB provides a snapshot data feed so the data does not come in any faster during fast markets.

    Unless you are writing very slow code you should never have a new tick come in before you are done processing the current tick.
  7. gkishot


    I have confused it with the realtimeBars method. My bad.
  8. chvid


    Make callMyBlackbox(price) synchronous and have tickPrice start a new thread. This will make tickPrice respond and exit immediately and make sure to process all requests in order and one at a time:

    public synchronized void callMyBlackbox(double price) {
    public void tickPrice(final int tickerId, final int field, final double price, final int canAutoExecute ) {
      new Thread() {
        public void run() {
    Maybe this will solve your problem?
  9. gkishot


    If the processing of each tick is slow then logically the data stream that you receive is too fast for your blackbox and therefore you have to skip some of the ticks. I don't see how you can get around it by processing each and every tick from TWS. You need some sort of synchronization mechanism between the ticks you receive per time unit and the ticks your system is capable to process per time unit.
  10. you don't want to do that because it will start a new thread on every single tick.

    seriously with IB it's not an issue because of their rate limiting.

    with other brokers that don't rate limit, it can be an issue depending on what sort of processing you are doing... if you are doing high latency calculations then you can lag the broker and they will reset your connections.

    what we do with tradelink to support all of these brokers is offer a class that will queue up ticks and process them asychronously on another thread... but inside of this thread the ticks are processed in sequence (and sychronously). see here :

    with IB though almost irregardless of what you're calculating you don't have to worry about this because they rate limit the feed.

    if you have a really specific example of why you think you might need threads, please share but otherwise don't mess with it. there is a lot of complexity to threads and it's often not worth the trouble.
    #10     May 6, 2009