Interactive Brokers - IB _Gateway_ memory leak when subscribing to options

Discussion in 'Retail Brokers' started by BulletTooth, Apr 6, 2011.

  1. Hi folks,

    I reported the following memory leak to IB API team sometime back, and their developers acknowledged it. But after following up with them a few times since early January, I was disappointed that they are still "investigating".

    I am posting it here, for one because I have seen the other issues that are reported here actually got addressed, so I am hoping to somehow get lucky with this issue as well. Also there must be other options traders who is in the same boat and found a workaround?

    It is naturally frustrating for me since I do need to rely on the IB platform at this point. IB is far from being rock solid itself but I have been able to build a robust system that has been running around the clock for months without a single issue, while fully subscribed to 200 most liquid futures and stocks symbols. So long as I don't touch options!

    /end rant

    So here goes:

    === My initial bug report in January ===========================

    I have a API client that subscribes to 90+ option contracts at the beginning of each trading day. (by calling reqMktData) The API client connects to an IB Gateway instance.

    I have been testing this client for a few weeks, and the IB Gateway process is very prone to out of memory exceptions, even after I assigned 1GB of memory to the gateway JVM I could not prevent such OOM exceptions. I think this has to do with the option models running inside the IBGateway.

    I will attach the IBGateway JVM stacktrace for your investigation, but I would like to turn off the option model computation via code or configuration. Please let me know how I can achieve this.


    java.lang.OutOfMemoryError: Java heap space
    at javax.swing.text.GapContent.allocateArray(
    at javax.swing.text.GapVector.resize(
    at javax.swing.text.GapVector.shiftEnd(
    at javax.swing.text.GapContent.shiftEnd(
    at javax.swing.text.GapVector.replace(
    at javax.swing.text.GapContent.insertString(
    at javax.swing.text.AbstractDocument.handleInsertString(
    at javax.swing.text.AbstractDocument.insertString(
    at javax.swing.text.PlainDocument.insertString(
    at javax.swing.JTextArea.append(
    at ibgateway.zb.a(Unknown Source)
    at jutils.dd.a(
    at jutils.dd.a(
    at jextend.p.stateChanged(
    at jutils.yf.a(
    at jutils.yf.a(
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
    at java.util.concurrent.ThreadPoolExecutor$

    ====== reply from API support =====

    On Jan 13, 2011 10:59 AM, <> wrote:

    Hello XXX,

    We are currently investigating this type of issue. I've believed that the Ib Gateway is getting some memory leak.

    IB API Support

    ====== sometime later ==============
    Date: Fri, 25 Feb 2011 11:55:21 -0500

    Hello XXXX,

    The development team is still investigating this issue.

    IB API Support
  2. After a couple more months they will tell you to exit TWS Gateway and restart it every day like they do their servers. IB has been told about this memory leak with TWS Gateway before (here - and do not seem to care. They seem to think that only being able to keep an app or service running for only a day or so uninterrupted is normal behavior unfortunately. // end rant 2 :)
  3. I am not really asking a lot. Either

    1) Fix the leak - not really hard since I have already pin-pointed the cause and showed them how to reproduce. A few heap dumps and a few hours testing should suffice. (assuming any competent developer at the task)

    2) OR just allow the users to turn off the option pricing models by configuration. I have no faith in IB to get the pricings right anyway, and their methodologies are not documented.

    I have tried to maximize the JVM heap settings and still was not able to make it through one day without bailing out. I don't really mind restarting my gateway instance after close.

    ps what you posted seem to be a different issue. A memory _leak_ as I have reported cannot be cured by configuration, but delayed garbage collection in JVM (link above) can be cured by fine-tuning. but Anyways. I still dream of being able to trade options with my ATS but that hope has faded now.
  4. samovar


    IB is getting on my nerves too.

    What would be the top alternatives to IB at the moment? API support, comparable commissions, better trading platform for automated trading.
  5. It seems there aren't any.

    Just restart the program once a day.
  6. DAV

    DAV ET Sponsor

  7. Thanks. I will try this out over the weekend and will update.

  8. This does not fix anything. I know the first thing to try is always to try to point users to a latest and greatest version, but this has to be taken up with the developers. Thanks for your reply though, I really appreciate it. Please take the attached log files and let the developers reproduce and fix the leak.

    Specifically, do the following:

    1. Have a IB gateway client connect to the gateway.

    2. Have the client subscribe for (reqMktData) for the most ATM options (say the 8 strikes on either side) for the first a few options expiry, on SPY.

    3. Let the client run, it will receive not only bid/ask/last, but also the greeks.

    4. Eventually (less than a trading day) the Gateway itself goes out of memory, or some other sort of error. (see log file)

    I have other use cases that proves to me that only with the options I have such problems. How do we turn off the leaking options models? This is a case where I don't even need you to fix it immediately, but provide a work around by letting the using turn OFF the options models. (since the IB gateway/TWS can't do it without a leak)

    Please see the log file attached. (of the gateway process)
  9. Oops, log file was too big, i had to truncate it. Attached below:
  10. DAV

    DAV ET Sponsor

    The new beta version of IB Gateway does includes memory optimization enhancements, but we have not been able to reproduce your issue BulletTooth. Please check your PMs.
    #10     May 12, 2011