Потеря лога, в случае исключения при вызове метода "Соединение.ВызватьHTTPМетод" about onesniffer HOT 10 CLOSED

@ViktorErmakov, прошу уточнить, рассматриваем варианты использования стороннего хранения логов, скажем параллельную запись в ЖР и в стороннюю систему?

from onesniffer.

@ViktorErmakov, прошу уточнить, рассматриваем варианты использования стороннего хранения логов, скажем параллельную запись в ЖР и в стороннюю систему?

На данном этапе нет, пока работаем в 1С.

from onesniffer.

@ViktorErmakov, прошу уточнить, рассматриваем варианты использования стороннего хранения логов, скажем параллельную запись в ЖР и в стороннюю систему?

На данном этапе нет, пока работаем в 1С.

Ок.
Кажется, пока в текущем варианте достаточно ЖР при условии контроля за его размерами. РС не нужен

from onesniffer.

@ViktorErmakov, прошу уточнить, рассматриваем варианты использования стороннего хранения логов, скажем параллельную запись в ЖР и в стороннюю систему?

На данном этапе нет, пока работаем в 1С.

Ок. Кажется, пока в текущем варианте достаточно ЖР при условии контроля за его размерами. РС не нужен

От РС я не готов совсем отказаться, это кажется не верно. В конечном виде записи логов должны быть в РС, и просматривать их надо из РС, не из ЖР напрямую. Из ЖР лишь можно считывать исключительные ситуации. Но нужно ли это вообще, ловить такие исключительные ситуации, и как их записывать, вот в чем изначальный вопрос.

from onesniffer.

@ViktorErmakov, прошу уточнить, рассматриваем варианты использования стороннего хранения логов, скажем параллельную запись в ЖР и в стороннюю систему?

На данном этапе нет, пока работаем в 1С.

Ок. Кажется, пока в текущем варианте достаточно ЖР при условии контроля за его размерами. РС не нужен

От РС я не готов совсем отказаться, это кажется не верно. В конечном виде записи логов должны быть в РС, и просматривать их надо из РС, не из ЖР напрямую. Из ЖР лишь можно считывать исключительные ситуации. Но нужно ли это вообще, ловить такие исключительные ситуации, и как их записывать, вот в чем изначальный вопрос.

Что именно неверно?
Какие задачи решает РС?
Какова актуальность данных логов в РС (как долго они там будут храниться)?
Кажется, его потенциал существенно ниже чем у ЖР, в части объемов и скорости записи.

from onesniffer.

Что именно неверно? Какие задачи решает РС? Какова актуальность данных логов в РС (как долго они там будут храниться)? Кажется, его потенциал существенно ниже чем у ЖР, в части объемов и скорости записи.

Цель этого расширения - быстрое чтение логов, я как разработчик подсистем использующих сторонние API ежедневно по многу раз смотрю эти логи, я конечно могу каждый раз читать из ЖР у меня база разработчика, вес ЖР не большой, но кому то это может сильно помешать, у кого ЖР весит очень много, поэтому любой функционал связанный с ЖР должен быть опциональным, а значит иметь замену.
По поводу хранения логов ты сможешь ответить на этот вопрос запустив расширение и посмотрев настройки.
По моим задачам логи нужны за сегодня день разработки, и вчера это автотесты. Дальше двух дней никогда не искал ничего.
Скорость записи у РС не многим отличается от записи в ЖР, и не так важны миллисекунды, а вот скорость чтения отображения логов очень важна в решении подобных мне задач.
И давайте сильно не отходить в стороны от вопроса топика. РС использоваться будет.

from onesniffer.

Еще раз поясню, выше метода "_ВызватьHTTPМетод" теоретически может быть открыта транзакция, поэтому в исключении мы даже если запишем логи, то они удаляться. Выражение "ВызватьИсключение" мы должны указать, что бы не было ошибок типа "в данной транзакции уже происходили ошибки".
Можно в исключении проанализировать активна ли транзакция, если да, то записать в ЖР, и все же на форме логов по кнопке эти записи доставать, а если транзакция не активна, то писать в лог прям в исключении, тем самым покрыв логами максимальное количество обращений.
Тогда мы сохраняем быстрое чтение логов, и по желанию пользователя он может достать исключительные записи которые были в транзакции, такого сам еще не встречал, но покрыты будут все варианты.

from onesniffer.

Что именно неверно? Какие задачи решает РС? Какова актуальность данных логов в РС (как долго они там будут храниться)? Кажется, его потенциал существенно ниже чем у ЖР, в части объемов и скорости записи.

Цель этого расширения - быстрое чтение логов, я как разработчик подсистем использующих сторонние API ежедневно по многу раз смотрю эти логи, я конечно могу каждый раз читать из ЖР у меня база разработчика, вес ЖР не большой, но кому то это может сильно помешать, у кого ЖР весит очень много, поэтому любой функционал связанный с ЖР должен быть опциональным, а значит иметь замену. По поводу хранения логов ты сможешь ответить на этот вопрос запустив расширение и посмотрев настройки. По моим задачам логи нужны за сегодня день разработки, и вчера это автотесты. Дальше двух дней никогда не искал ничего. Скорость записи у РС не многим отличается от записи в ЖР, и не так важны миллисекунды, а вот скорость чтения отображения логов очень важна в решении подобных мне задач. И давайте сильно не отходить в стороны от вопроса топика. РС использоваться будет.

Если данные только за два дня, РС подходит в первом приближении

from onesniffer.

вот что я имел ввиду выше

from onesniffer.

Решено

from onesniffer.