[ts-gen] Event-Driven Programming in Ruby Downstream

Ken Feng kfmfe04 at gmail.com
Mon Sep 14 20:55:46 EDT 2009


Thanks to everyone's help on this mailing list, I am finally doing
some real testing/debugging on a paper account.

One outstanding design issue for me has been Downstream Ruby Event-Handling.

Just in Ruby, there appears to be many approaches:

1. popen3() and select() (recommended by Bill)
2. popen3() and threads (my current setup)
3. Ruby/EventMachine
4. Ruby/ruby-event
5. Others?

My 2. approach appears to work okay for me, but I am not 100%
confident (it's hard to be with threads) until I can test some more.
I had to upgrade from 1.8.7 (green threads) to  2.9.1 (OS threads), as
I was getting some strange interactions and reliability issues between
threads and gets()  in 1.8.7.  2.9.1 seems to be working more
reliably.

I am currently investigating 3. and 4. - there are some posts on the
EventMachine website claiming that a tightly-optimized asynchronous
loop is much more efficient than using threads or processes.  More
importantly, besides efficiency improvements, I believe the code can
become much cleaner/easier-to-maintain with an event-driven framework.

I think picking a good event-driven model will be crucial in the last
stage where we all need to code for the dreaded "hung out in left
field states" where the line drops, TWS/IB loses exchange connections,
etc...  I am not there yet, but I can definitely envision the
nightmare of trying to write readable/maintainable code for all the
strange states that the downstream client may have to face, not even
considering how to ensure that the code works as expected.

When I find out more, I will share my findings on the list.

- Ken

Updates on Past Issues:

(Aside #1: thanks to Bill's tireless efforts to post detailed
descriptions of the shim architecture, it looks like I was able to
implement my "poor man's OCA order" in the downstream Ruby layer.  My
approach was to keep track of OCA tags in my own orders table.  Upon
receipt of a full or partial fill, I would SELECT all 'var's which
have same OCA tag as the filled order, excluding the row for the
filled order itself.  I would then Cancel all those orders via the
'var' order_tag.

Aside #2: for those of you interested, it appears to be possible to
keep TWS/IB and Shim up reliably for an entire week.  I had to switch
from "select bars" to "select ticks" for data as I had problems with
the historical data servers, but so far, "select ticks" seems to work
much more reliably.  I still haven't handled the case where IB's
exchange servers go down due to DNS/routing problems, because I
haven't seen a case recently.  However, overall, it looks like keeping
TWS/IB/Shim up for a week is doable.)


More information about the ts-general mailing list