← Назад

Плюшки: Снятие активных заявок по условию

В классе стратегии есть метод снятия всех активных заявок. Он вроде бы производит безопасный внутренний лок для коллекции информации по заявком, не доступной извне. (почему бы не сделать поля protected?) Т.е. снятие активных заявок из своего кода может быть менее безопасно. Тем более, что добавить нужный фунционал в Strategy - пара пустяков ;)

Вобщем добавил в метод снятия заявок необязательный параметр условия снятия, а также его логирование. Немного усовершенствовал для этого метод Filter в хелпере. Оверхед от обработки дополнительного условия - 0.4 ms.

Кстати, почему обычный метод снятия одной заявки не проверяет её активность? Можно снять заявку с каким-либо другим статусом?

Комментарии (7)

Вход или Создать аккаунт, Войдите или зарегистрируйтесь, чтобы оставить комментарий

Sergey Masyura
Sergey Masyura

VassilSanych: В классе стратегии есть метод снятия всех активных заявок. Он вроде бы производит безопасный внутренний лок для коллекции информации по заявком, не доступной извне. (почему бы не сделать поля protected?) Т.е. снятие активных заявок из своего кода может быть менее безопасно. Тем более, что добавить нужный фунционал в Strategy - пара пустяков ;)

Вобщем добавил в метод снятия заявок необязательный параметр условия снятия, а также его логирование. Немного усовершенствовал для этого метод Filter в хелпере. Оверхед от обработки дополнительного условия - 0.4 ms.

Кстати, почему обычный метод снятия одной заявки не проверяет её активность? Можно снять заявку с каким-либо другим статусом?

http://en.wikipedia.org/wiki/Diff

VassilSanych
VassilSanych Автор
Sergey Masyura
Sergey Masyura

VassilSanych:

Sergey Masyura: http://en.wikipedia.org/wiki/Diff Это к чему?

К Вашему сведению.

VassilSanych
VassilSanych Автор

Не совсем понял. Файлы по содержимому даже Total Commander нормально сравнивает. Я обычно пользуюсь Beyond Compare, потому что там 3-way сравнение, удобное для мержа. Но при чём тут моя тема?

ra81
ra81

VassilSanych: Кстати, почему обычный метод снятия одной заявки не проверяет её активность? Можно снять заявку с каким-либо другим статусом? я думаю потому что проверить ее активность задача стратегии перед снятием. Если снимать будем исполненную все равно схлопочем ошибку. Опять же в момент снятия она уже может исполниться, так что это проверять придется всегда :).

Забивать лишний функционал в снятие заявки, имхо излишество.

VassilSanych
VassilSanych Автор

ra81: Забивать лишний функционал в снятие заявки, имхо излишество. Просто я сейчас тестирую снятие лимитной заявки по достаточно короткому таймауту. Причём стратегия тоже довольно быстрая - как раз для отладки. Так вот: чуть ли не каждое второе снятие напарывается на ошибку, что заявка уже снята (или исполнилась или снялась при формировании встречной) И это при том, что в логе сначала отображаются события, означающие отмену заявки, а потом валится ошибка снятия. Правда таймаут не очень большой 50-160 мс. Какая, кстати, обычно латентность снятия или реакции на отмену заявки, если латентность регистрации 220+/-40 мс?

ra81
ra81

VassilSanych:

ra81: Забивать лишний функционал в снятие заявки, имхо излишество. Просто я сейчас тестирую снятие лимитной заявки по достаточно короткому таймауту. Причём стратегия тоже довольно быстрая - как раз для отладки. Так вот: чуть ли не каждое второе снятие напарывается на ошибку, что заявка уже снята (или исполнилась или снялась при формировании встречной) И это при том, что в логе сначала отображаются события, означающие отмену заявки, а потом валится ошибка снятия. Правда таймаут не очень большой 50-160 мс. Какая, кстати, обычно латентность снятия или реакции на отмену заявки, если латентность регистрации 220+/-40 мс? И регистрация и снятие одинаковой скоростью идут обычно. От брокера тут сильно зависит тоже. В любом случае никакая плюшка не спасет от таких ошибок регистрации и снятия. Они будут если заявки часто валятся. Потому как мы сидим далеко от биржи и до нас пока дойдет уже сто раз исполнится.