app/charts: show epoch limit orders on depth chart #348
Conversation
| @@ -34,7 +34,7 @@ type BookFeed struct { | |||
| // feed when it's no longer being used. | |||
| func NewBookFeed(close func(feed *BookFeed)) *BookFeed { | |||
| return &BookFeed{ | |||
| C: make(chan *BookUpdate, 1), | |||
| C: make(chan *BookUpdate, 256), | |||
There was a problem hiding this comment.
Did you experience a deadlock on a send or is this a performance consideration?
There was a problem hiding this comment.
Whoops. Never submitted my self-review.
| @@ -34,7 +34,7 @@ type BookFeed struct { | |||
| // feed when it's no longer being used. | |||
| func NewBookFeed(close func(feed *BookFeed)) *BookFeed { | |||
| return &BookFeed{ | |||
| C: make(chan *BookUpdate, 1), | |||
| C: make(chan *BookUpdate, 256), | |||
There was a problem hiding this comment.
I ran into this in the test, and I think it's a risk during normal operations too, since the server sends updates for newly booked orders in rapid succession after matching.
There was a problem hiding this comment.
The problem I'm trying to avoid is at
Lines 128 to 133 in 9efbc84
but it raises the question of whether that's the right pattern.
There was a problem hiding this comment.
I was battling with a similar challenge in #287 with sends on the orderRouter channel, resolved in commit edbf282. Ideally the channel buffer should only be a performance consideration (at least beyond a buffer of 1), and things should work if the buffer fills up. It's tough to be sure, but in the market's case it was a matter of proper synchronization between the sender and receiver so that the sender can guarantee there's a receiver on send. I'll give a proper review of this PR asap.
| switch { | ||
| case r < 0.33: | ||
| // Epoch order | ||
| trySend(&core.BookUpdate{ | ||
| Action: msgjson.EpochOrderRoute, | ||
| Order: randomOrder(rand.Float32() < 0.5, c.maxQty, c.midGap, 0.05*c.midGap, true), | ||
| }) | ||
| case r < 0.76: | ||
| case r < 0.80: |
There was a problem hiding this comment.
All new orders are being sent as epoch orders.
| }) | ||
| } | ||
| c.trySend(epochOrder) | ||
| c.epochOrders = append(c.epochOrders, epochOrder) |
There was a problem hiding this comment.
Epoch orders are cached for "matching".
| @@ -34,7 +34,7 @@ type BookFeed struct { | |||
| // feed when it's no longer being used. | |||
| func NewBookFeed(close func(feed *BookFeed)) *BookFeed { | |||
| return &BookFeed{ | |||
| C: make(chan *BookUpdate, 1), | |||
| C: make(chan *BookUpdate, 256), | |||
There was a problem hiding this comment.
Whoops. Never submitted my self-review.
Shows epoch limit orders as a phantom layer on top of the order book. Differentiating is important here, because the epoch orders may or may not have processed by the time a placed order matches, so the epoch layer is not as likely to be matchable.
Shows epoch limit orders as a phantom layer on top of the order book. Differentiating is important here, because the epoch orders may or may not have processed by the time a placed order matches, so the epoch layer is not as likely to be matchable.
Updates to the test app server to more realistically handle epochs.