double fills

[rv]

This is has happened to me twice. JBT sends an order, somehow, can't
get the execution details and then places another order. Both get
eventually filled. But the fill details of the 1st orders get lost.
JBT thinks it is long 1 lot but actually it is long 2 lots.

I am thinking of commenting out the following two lines of code in
Trader.execDetailsEnd(int reqId)

openOrders.clear()
traderAssistant.resetOrderExecutionPending();

any suggestions ?

07/19/11 21:22:05.193 IB API 2104: Market data farm connection is
OK:aufarm
07/19/11 21:22:05.193 JBookTrader Checking for executions while TWS
was disconnected from the IB server.
07/19/11 21:22:05.193 EUR_Momentum Requesting executions for open
order 217
07/19/11 21:22:05.232 EUR_Momentum Order 217: Execution for this order
was not found. In all likelihood, this is because the order was placed
while TWS was disconnected from the server. This order will be removed
and another one will be submitted. The strategy will continue to run
normally.
07/19/11 21:22:06.001 EUR_Momentum Placing order 218
07/19/11 21:22:06.287 EUR_Momentum Order 218 is filled. Average fill
price: 1.41668. Position: 100000

[Eugene Kononov]

Thanks for your report. I've had hundreds of orders executed with JBT, never had this problem. Can you post a larger section of your event report, starting from the moment when JBT first attempted to place order #217?

--
You received this message because you are subscribed to the Google Groups "JBookTrader" group.
To post to this group, send email to jbook...@googlegroups.com.
To unsubscribe from this group, send email to jbooktrader...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jbooktrader?hl=en.

[rv]

here is the full log ..


07/19/11 21:22:05.001 EUR_Momentum Placing order 217

07/19/11 21:22:05.193 IB API 2104: Market data farm connection is
OK:aufarm
07/19/11 21:22:05.193 JBookTrader Checking for executions while TWS
was disconnected from the IB server.
07/19/11 21:22:05.193 EUR_Momentum Requesting executions for open
order 217
07/19/11 21:22:05.232 EUR_Momentum Order 217: Execution for this order
was not found. In all likelihood, this is because the order was placed
while TWS was disconnected from the server. This order will be removed
and another one will be submitted. The strategy will continue to run
normally.
07/19/11 21:22:06.001 EUR_Momentum Placing order 218
07/19/11 21:22:06.287 EUR_Momentum Order 218 is filled. Average fill
price: 1.41668. Position: 100000

i trade a lot using jbooktrader - 20-30 trades per day; is it possible
that because of the volume the bug is observed simply by virtue of
being a larger sample.

[Eugene Kononov]

i trade a lot using jbooktrader - 20-30 trades per day; is it possible
that because of the volume the bug is observed  simply by virtue of
being a larger sample.

Yes, that's probably the case.

By looking at your report, I think I know what the problem is. Before I state it, I'd like to see what happened before  21:22:05.001. Was there a reference to a lost connection to TWS?

[rv]

None. There is no reference to jbt being disconnected before the
following line :

07/19/11 21:22:05.193 JBookTrader Checking for
executions while TWS
was disconnected from the IB server.

[Eugene Kononov]

On Wed, Jul 20, 2011 at 10:21 PM, rv <raj...@gmail.com> wrote:

None. There is no reference to jbt being disconnected before the
following line :

Ok, good, this validates my theory. Here is what I think is happening.

Imagine the scenario when JBT submits an order, the TWS sends it to the exchange, and the connection between TWS and IB is lost (which happens occasionally).  Next, the order is executed by the exchange, the confirmation is sent to IB, and IB sends it back to TWS. Since TWS is at this point disconnected from IB, the order confirmation never reaches TWS. After the connection is restored, JBT would wait indefinitely for the confirmation of execution. Another scenario is this: JBT submits an order, connection between TWS and IB is lost immediately after, so the order never reaches the IB. To work around these two situations, JBT has logic in place which makes an explicit request for executions, and attempts to find the order confirmation in the response. This logic kicks in after errorCode 1101 or errorCode 1102 are received, indicating that the connection was restored. You can see this code in Trader.java. All of this works well, except that sometimes, neither error code 1101 nor 1102 are sent after the reconnection. As a result, JBT would never invoke the explicit check for executions. So, as a fix to this problem, JBT also uses code 2104 as an indication that the connection was restored, and uses this as a trigger for the check for executions. See line 140 in Trader.java.

As it turns out, that code 2104 does not necessarily indicate that the connection with TWS was lost, but instead that the data farm is "OK".

So, in your case, as indicated in your report, here is what happened:

21:22:05.001  everything is cool and connected, JBT places order 217
21:22:05.193  JBT gets the error 2104: Market data farm connection is OK:aufarm
21:22:05.193  Because of error 2104, JBT thinks that there was a period of disconnection, so it requests executions for order 217
21:22:05.232  Only 231 milliseconds have passed since order 217 was submitted, so that order didn't get executed yet. However, JBT thinks that since there is no record of order 217, it must have been because it never reached IB because there was a disconnection.
21:22:06.001   JBT discards order 217 and places order 218
21:22:06.287   Order 218 is filled. Order 217 is also eventually filled, but JBT had previously discarded it. The end result is that both order have been executed, while JBT thinks only one got through.

So, that's the cause of the problem. As can be seen, Trader.java contains some hacks to address bugs in IB API. However, this code was put long time ago, and since them, the API was upgraded several times. So, it's quite possible that these IB API bugs were fixed. If that's the case, then the fix to your "double fill" problem is simply to replace line:
            boolean isConnectivityRestored = (errorCode == 1101 || errorCode == 1102 || errorCode == 2104);
with line
            boolean isConnectivityRestored = (errorCode == 1101 || errorCode == 1102);

No other code changes are necessary. However, if the IB API bug is still there (failing to send 1101 or 1102 on reconnect), then we should look for another solution. A fairly obvious alternative solution is to delay the explicit request for executions after the reconnection by a couple of seconds, if there is a pending order which was submitted recently (in the previous couple of seconds, that is). That seems rather hacky, though. If anyone can think of a better way to handle this, I am open to suggestions.

[rv]

Eugene, I commented out 2104 condition. Lets wait and see if this
happens again.

Thanks for your help. Also, btw, jbt is a pretty neat piece of
software. Great job!

-Rajiv

On Jul 20, 11:03 pm, Eugene Kononov <eugene.kono...@gmail.com> wrote:

[nonlinear]

Eugene, I commented out 2104 condition. Lets wait and see if this
happens again.

Ok, cool. Please keep me in the loop in regards to this thing. And thanks for reporting this interesting corner case. It's a subtle bug, for sure.

 

[rv]

Eugene, It seems your solution has worked. Despite heavy trading
activity, I haven't received double fills ever since I put this fix in
place.

[Eugene Kononov]

Ok, good, I'll include this in the next release. Thanks for reporting and retesting.