Техническая реализация запрета продажи маркированных товаров : Маркировка

не убедил :) трассировку от курла покажи, а то вдруг твой терминальный сервер очередь организует или еще какие коллизии :)
но в принципе если уверен что нашел виновника - то нет проблем - как я и написал выше дискуссию можно сворачивать

да, я уверен (и раньше грешил всегда на курл, а сейчас прям через процессы - сверил терминальные имена РМК с именами в процессах - всё совпало - и количество "зависонов" и сами РМК..)
а выше - я сообщал, что возможно такое нестабильное поведение курла связано с довольно древней ОС, либо с терминальным режимом..
но задачи доказать прям свою правоту, разбивши лоб, - у меня не было, и нет..
просто мне интересно всегда докопаться до сути проблемы, считаю, - что докопался, ну и надеюсь, что эта информация будет полезна и другим (а заодно - и один из способов предупредить подобное через подобный моему "костыль")

Так что - виновник, будем считать, определён, решение - тоже предоставлено, поэтому в дальнейшем в этой теме будем дискутировать уже не на эту проблему, а на другие проблемы, которые ещё точно возникнут в процессе технической реализации проверки КМ (чему эта тема и посвящена).

Спасибо за приятную предыдущую дискуссию и за помощь докопаться до истины (я в этом уже уверен)
;)

Да, как только магазины закрылись и РМК выключились - автоматически удалились и зависшие процессы "curl.exe" по этим терминальным клиентам.
Ну и отлично ;)

после наблюдений за своими логами в течение нескольких дней - что-то и у меня уже подозрения возникли, что дело конечно-же в курле (именно он зависает, тут сомнений нет), а вот почему он зависает (причины зависания) - похоже я в ближайшее время и определю (если конечно мои догадки - подтвердятся.. копать просто нужно долго и глубоко.. но я - в душе археолог, покопаюсь на досуге..)

Покопался, но причины спонтанных зависаний curl (почему даже при ассинхронном запуске curl-а его опции по таймауту не срабатывают, и он остаётся висеть в процессах) - я так и не понял (также ещё грешил на сами КМ, при которых curl зависал, но при повторной проверке этих же КМ (временно включал автоматическое немедленное повторение попытки отправки запроса после первого срабатывания "костыля") - зависаний уже не было).
Ну и ладно пока, оставлю как есть, на работу РМК это не влияет (других задач полно, кроме выяснения причин этого "глюка").

Возвращаясь к таймаутам курла и к Методическим Рекомендациям:

В МР - написано:
Получается, что если через 1,5 сек. не получен ответ (неважно, сколько было запросов и повторялись ли они), то разработчики МР рекомендуют дальше не тратить время на запросы, а пропустить эту онлайн проверку.
Я правильно понял их идею?

Тогда у меня вопросы следующего плана:
1. У тебя сколько времени отводится в твоей УС на проверку одного КМ? (какое ограничение по таймауту?)
2. Это ограничение ты задаёшь параметрами curl? (в случае его использования)? Если да, то какие значения X и Y ставишь в --connect-timeout X --max-time Y ?
А если не параметрами curl, то каким способом? (я вот, например, выше показывал костыль (цикл на проверку файла ответа), с помощью которого могу устанавливать нужные мне параметры таймаута). А у тебя как сделано (или как планируешь сделать)?

на наш взгляд ключевое здесь
т.е. фактически пропускать ты можешь до апреля, для отдельных групп срок больше, но смысла не меняет - запрет будет, так что по моему кассиров надо приучать с малолетсва :)

насчет таймаутов - дефолт 10 и 20 но все задается настройками - все что можно у нас через них, в т.ч. и реакция на отсутствие связи с серверами црпт - т.е. мы ничего жестко не прописываем - пользователь принимает решение самостоятельно - мы только даем ему такую возможность :)

Я правильно понял:
1. Если пользователь твоей УС в настройках поставит 1,5 сек., то технически это будет означать установку параметров в curl
--connect-timeout 1.5 --max-time 1.5 ? (меня не интерфейс пользователя интересует, а что происходит у тебя с параметрами curl)
2. Лично твоё мнение - я правильно понимаю, что разработчики МР рекомендуют на все онлайн (именно онлайн) проверки одного КМ - отводить не более 1,5 сек.? Или я неправильно понимаю рекомендации? Тогда как ты их понимаешь? (твоё личное мнение)

это я пробовал, но т.к. асинхронно запускаю curl (а синхронно уже не хочу, ибо РМК опять придётся продавцам перезагружать в случае зависания) - то возникают проблемы:
1. файл, который указываю в параметрах --trace-asci - затирается заново с каждым запуском curl, и как поймать (скопировать) этот файл именно у зависшего curl - не понимаю (или как заставить не перезаписывать файл, а дописывать.. создавать каждый раз новый файл с трассировкой - не хочу, это ж сколько у меня их расплодится)
2. если curl завис - то этот файл (с результатом трассировки) всё-таки будет создан, или не будет (раз curl повесился)?
если будет, то тогда проблему 1 решить можно (вывернуться), а если нет - то тогда всё бесполезно... мне вот кажется - что если curl повесился (что аж в процессах висит, пока принудительно не завершить), то и файл с трассировкой он не создаст
...
потом как-нибудь ещё возможно и вернусь к этим экспериментам, но если знаешь ответы - напиши сразу, чтобы мне меньше мучиться.. ;)

насчет дробных секунд - х\з - не проверял, но склонен к тому что надо устанавливать разные значения - все таки это таймауты соединения и максимальное время операции а так - все индивидуально т.е. кому как нравится и кто к чему привык :)

да, они типа декларируют что все проверки не будут тормозить очередь на кассе и все должно уложиться в 1.5 сек