_sk_ написал: У меня была такая проблема. Разработчики больше не поддерживают 7-ю версию терминала. Откатитесь на версию 7.16 (там ещё нет этой ошибки) или перейдите на 8.1 (там уже нет этой ошибки).
А вообще, плохо, конечно, что последний релиз 7-й версии терминала оказался таким вот образом сломан.
После снятия заявки из скрипта хотел перевыставлять снятый остаток, но обнаружил, что в коллбек OnTransReply приходит сообщение содержащее в поле balance дробное значение. Можете зарегистрировать обращение на исправление? Если нужны дополнительные данные - готов предоставить.
Возникает проблема приводящая к тому, что квик съедает максимум доступной ему оперативной памяти. Если закрыть квик, он дампит в файл info.wnd большое количество данных, которые он вычитывает при следующем запуске (из-за чего стартует долго) и загружает в память, из-за чего снова возникает проблема с недостатком памяти. Для ее устранения необходимо удалить info.wnd.
Чтобы убедиться, что память потребляет именно квик а не скрипт написал пример, скрипт выводит раз в минуту информацию об использованной памяти:
Скрытый текст
Код
os.setlocale("")
local Server = require "modules.Server";
local Logger = require "modules.Logger";
local Utils = require "modules.Utils";
local Quik = require "modules.Quik";
local Logger = require "modules.Logger";
local Timer = require("modules.Timer")
local base = _G;
local math = math;
local string = string;
local timer = Timer:new()
local logger;
local worker = true
local function GetSecurities(class)
local sec_list = {}
local sec_str = getClassSecurities(class)
local sec_tab = {}
for security in sec_str:gmatch("[^,]+") do table.insert(sec_tab, security) end
for index, sec_code in pairs(sec_tab) do
info = getSecurityInfo (class, sec_code)
if info then
sec_list[sec_code] = {}
sec_list[sec_code]["class_code"] = class
sec_list[sec_code]["sec_code"] = info["isin_code"]
sec_list[sec_code]["stock_code"] = info["stock_code"]
else
logger: debug('GetSecurities: Not receive info for '..sec_code..', '..class)
end
end
return sec_list
end
local function quotesSubscribe(securities)
for sec, values in pairs(securities) do
if not Subscribe_Level_II_Quotes(values["class_code"], values["sec_code"]) then
logger: warn('quotesSubscribe: Failed subs for '..values["sec_code"]..', class: '..values["class_code"])
end
end
logger: info('quotesSubscribe: Subscribed')
end
local function paramsSubscribe(securities)
for sec_code, values in pairs(securities) do
if not ParamRequest(values["class_code"], values["sec_code"], "BID") then
logger: warn('paramsSubscribe: bid subs failed for '..values["sec_code"]..', class: '..values["class_code"])
end
if not ParamRequest(values["class_code"], values["sec_code"], "OFFER") then
logger: warn('paramsSubscribe: offer subs failed for '..values["sec_code"]..', class: '..values["class_code"])
end
end
logger: info('paramsSubscribe: Subscribed')
end;
function OnQuote(class_code, sec_code)
if class_code == "F" then
logger: debug('F')
end
end;
function OnParam(class_code, sec_code)
if class_code == "F" then
logger: debug('F')
end
end;
function OnInit()
local scriptPath = getScriptPath();
logger = Logger: new(scriptPath, "test.log", "testtg.log", dump);
end;
function OnStop()
worker = false
end;
function OnConnected()
worker = true
end;
function OnDisconnected()
worker = false
end;
function main()
local sec_list = GetSecurities("NYSE_BEST")
quotesSubscribe(sec_list)
paramsSubscribe(sec_list)
local sec_list = GetSecurities("NASDAQ_BEST")
quotesSubscribe(sec_list)
paramsSubscribe(sec_list)
timer:setInterval(60)
while worker do
sleep(1)
if timer:isTimeout() then
logger: debug("Memory quik used: " .. math.ceil(getInfoParam("MEMORY") / 1024).. "M")
logger: debug("Memory lua used: " .. math.ceil(collectgarbage("count") / 1024) .. "M")
timer:setInterval(60)
end
end
end;
Как можно решить данную проблему без перезапуска квика и удаления info.wnd? Из-за чего образуется потребляется столько оперативной памяти? Как уменьшить можно потребление?
Заявка отправляется с типом IOC. Это несколько меняет логику, получается по такому типу заявок можно получить флаг исполнения в сообщении получаемом при обработки OnOrder только при полном исполнении?
Что в первом, что во втором примере заявка исполнилась только частично
Не понятно зачем гадать. Флаги описаны в документации QLUA.chm -Описание битовых флагов --Флаги для таблиц Заявки, Заявки на внебиржевые сделки, Сделки, Сделки для исполнения
Я не гадаю, это и есть интерпретация на основе документации
Цитата
у Вас флаги flags=286. В битовом представлении это число 100011110 Видим что 0x1 равен 0, а 0x2 равен 1. Согласно документации это значит что заявка снята. И на скриншоте она у Вас снята. И по reject_reason она снята. Почему Вы думаете что она исполнена совсем не понятно. Посмотрите сами в таблице заявок, колонка Статус
Это скриншот таблицы сделок, заявка была исполнена, есть биржевой номер.
Цитата
"кросс сделка" это потенциальная сделка с самим собой. Возможно в момент срабатывания заявки у Вас была активна другая заявка противоположного направления? В любом случае, как Вы на нее наткнулись подскажет только брокер.
Мне кажется Вы не совсем полностью рассмотрели второй пример или вообще не посмотрели, давайте опишу его словесно, чтобы стало понятнее:
1. Я отправил заявку с типом FOK (Полностью или отклонить), получил подтверждение что она принята с номером 39888085050 2. Я получил несколько экземпляров OnTrade с частичным исполнением заявки под номером 39888085050 3. Я получил OnOrder по уже частично исполненной заявке 39888085050 со статусом rejected="Вследствие возможной кросс-сделки", и флагами, что заявка снята. 4. После я получил вторую пачку сообщений OnTrade с второй частью исполнения на 10 лотов (не добавил кусок лога)
Является ли валидной ситуация в которой я получил две сделки и статус по заявке - снята с причиной rejected="Вследствие возможной кросс-сделки"?
Если я правильно обрабатываю поле, то мне пришли следующие флаги: flag1 - Заявка снята flag2 - Заявка на продажу flag3 - Заявка лимитная flag4 - Разрешить сделки по разным ценам flag8 - Снять остаток
При этом заявка была исполнена (на время не обращайте внимание, у меня рассинхронизация между логом и сервером, OnTrade к сожалению записывал):
1. Насколько я понимаю, флаги в данном случае заполнились неверно? И причина описанная в reject_reason тоже невалидная? Как правильно определить что заявка с типом FOK была исполнена при обработке OnOrder ? 2. Почему по бирже СПБ приходят два одинаковых callback в OnOrder ?