DS
что мешает?
Да хз, так в целом возможность мемори лика или ещё каких-то непредвиденных последствий внутри аппликейшна/фреймворка. От греха, как говорится.
Size: a a a
2021 January 13
O
Просто брокер иногда подкидывает свинью, особенно при переключении нод AlwaysOn. Думаем отказаться от него.
можете задизайнить свой собственный брокер. таблица с очередью, поток разбирающий очередь с READPAST
G
Denis Suhotin
Да хз, так в целом возможность мемори лика или ещё каких-то непредвиденных последствий внутри аппликейшна/фреймворка. От греха, как говорится.
страхи из 90-ых и опенсурса %)
E
А мне говорили, что агент не начнет новую сессию пока не выполнит старую
IC
можете задизайнить свой собственный брокер. таблица с очередью, поток разбирающий очередь с READPAST
Принципиально так и решили, но времени на разработку пока не хватает :( Не первый приоритет.
O
А мне говорили, что агент не начнет новую сессию пока не выполнит старую
Он не даст джобу запуститься, если прошлый запуск не закончен
O
Принципиально так и решили, но времени на разработку пока не хватает :( Не первый приоритет.
можете запилить на виндовом шедуллере. он умеет килять текущее выполнение, если подошло время следующего
DS
страхи из 90-ых и опенсурса %)
Не, из ахапты. Там проблема с деаллокацией unmanaged объектов в CLR. Но ваще это не только там такая проблема актуальна может быть.
G
в скуле на дотнете наверное тока гуй
O
Denis Suhotin
Не, из ахапты. Там проблема с деаллокацией unmanaged объектов в CLR. Но ваще это не только там такая проблема актуальна может быть.
Ага, AX "хорош"
АА
Denis Suhotin
Не, из ахапты. Там проблема с деаллокацией unmanaged объектов в CLR. Но ваще это не только там такая проблема актуальна может быть.
unmanaged припоминаю из практики может при падении и экземпляр целиком с собой забрать.
AS
ILYA
Ну сделайте степ с бесконечным циклом типа while 1=1 в котором будет ваша процедура, а джобу достаточно будет тогда запустить один раз и просто проверяйте работает она или нет
Проблема в том, что процедура периодически падает с ошибкой. Теоретически, я могу выставить Retry Attemts 99999, но это уже не бесконечное выполнение, за этим придется следить и закончатся эти Retry Attemts, как обычно, в самое неподходящее время. Можно конечно создать второй джоб, который будет отслеживать статус первого и поднимать его в случае падения) Просто мне казался вариант с шедулером немного более долговечным.
DS
unmanaged припоминаю из практики может при падении и экземпляр целиком с собой забрать.
Ну там базовые объекты в unmanaged. Выходит, что если написано что-то вида
while (true)
{
Set crap = new Set(...);
}
и это уходит выполняться в CLR (а в актуальной версии весь x++ рантайм ушел в CLR), то сеты копятся и в какой-то момент она превращается в тыкву.
while (true)
{
Set crap = new Set(...);
}
и это уходит выполняться в CLR (а в актуальной версии весь x++ рантайм ушел в CLR), то сеты копятся и в какой-то момент она превращается в тыкву.
G
Alexander Shishkin
Проблема в том, что процедура периодически падает с ошибкой. Теоретически, я могу выставить Retry Attemts 99999, но это уже не бесконечное выполнение, за этим придется следить и закончатся эти Retry Attemts, как обычно, в самое неподходящее время. Можно конечно создать второй джоб, который будет отслеживать статус первого и поднимать его в случае падения) Просто мне казался вариант с шедулером немного более долговечным.
чо мешает в джобе сделать try?
O
Alexander Shishkin
Проблема в том, что процедура периодически падает с ошибкой. Теоретически, я могу выставить Retry Attemts 99999, но это уже не бесконечное выполнение, за этим придется следить и закончатся эти Retry Attemts, как обычно, в самое неподходящее время. Можно конечно создать второй джоб, который будет отслеживать статус первого и поднимать его в случае падения) Просто мне казался вариант с шедулером немного более долговечным.
виндовый шедуллер в таком случае в самый раз.
АА
Denis Suhotin
Ну там базовые объекты в unmanaged. Выходит, что если написано что-то вида
while (true)
{
Set crap = new Set(...);
}
и это уходит выполняться в CLR (а в актуальной версии весь x++ рантайм ушел в CLR), то сеты копятся и в какой-то момент она превращается в тыкву.
while (true)
{
Set crap = new Set(...);
}
и это уходит выполняться в CLR (а в актуальной версии весь x++ рантайм ушел в CLR), то сеты копятся и в какой-то момент она превращается в тыкву.
А я то думаю чего знакомые плачутся, что ушатались уже с АХ... Скуль и скуль., а тут вот оно что теперь...
DS
А я то думаю чего знакомые плачутся, что ушатались уже с АХ... Скуль и скуль., а тут вот оно что теперь...
Не, ну это не такая уж прям проблема, если конечно кто-то не смекнул бесконечный джоб сделать. Когда clr тред заканчивает работу, то все деаллоцируется конечно. И как правило основные ожидания - это отклик от СУБД, тут утечки - это скорее вопрос стабильности, а не скорости. Впрочем это не по ах чат.
Я просто к тому, что скуле тоже, мне кажется, не мало неочевидных мест, где что-то может подкапливаться и вылиться в то, что, условно, спустя месяц аптайма можно обнаружить, что те же самые запросы вместо 100мс работают 300мс, из-за того, что какой-нить version store не успевает разгребать.
Но я понял, что в целом с бесконечными циклами каких-то принципиальных проблем вроде как нет, спасибо.
Я просто к тому, что скуле тоже, мне кажется, не мало неочевидных мест, где что-то может подкапливаться и вылиться в то, что, условно, спустя месяц аптайма можно обнаружить, что те же самые запросы вместо 100мс работают 300мс, из-за того, что какой-нить version store не успевает разгребать.
Но я понял, что в целом с бесконечными циклами каких-то принципиальных проблем вроде как нет, спасибо.
АА
Denis Suhotin
Не, ну это не такая уж прям проблема, если конечно кто-то не смекнул бесконечный джоб сделать. Когда clr тред заканчивает работу, то все деаллоцируется конечно. И как правило основные ожидания - это отклик от СУБД, тут утечки - это скорее вопрос стабильности, а не скорости. Впрочем это не по ах чат.
Я просто к тому, что скуле тоже, мне кажется, не мало неочевидных мест, где что-то может подкапливаться и вылиться в то, что, условно, спустя месяц аптайма можно обнаружить, что те же самые запросы вместо 100мс работают 300мс, из-за того, что какой-нить version store не успевает разгребать.
Но я понял, что в целом с бесконечными циклами каких-то принципиальных проблем вроде как нет, спасибо.
Я просто к тому, что скуле тоже, мне кажется, не мало неочевидных мест, где что-то может подкапливаться и вылиться в то, что, условно, спустя месяц аптайма можно обнаружить, что те же самые запросы вместо 100мс работают 300мс, из-за того, что какой-нить version store не успевает разгребать.
Но я понял, что в целом с бесконечными циклами каких-то принципиальных проблем вроде как нет, спасибо.
Ну я тоже в детали тех проблем с АХ у коллег не вникал пока, может у них вообще они и не с этим связаны вовсе.
ВБ
Alexander Shishkin
Просто упростил, чтобы суть вопроса лучше передать) Стоит задача сделать непрерывное выполнение процедуры средствами SQL Agent. Пока придумали задание, которое выполняется раз в час, и в нем цикл, который смотрит на текущее время и выполняется только если оно не "перевалило" за текущий час. Вроде кажется, что непрерывность достигнута, но случается такое, что последняя выполняемая процедура выполнялась чуть дольше обычного и "перевалила" за час, и следующий джоб пропускается.
Джоб можно запускать и раз в минуту, и раз в секунду, всё равно новое задание не стартует пока предыдущее задание не завершилось. Ставьте запуск раз в секунду и пускай работает без всяких циклов и прочих танцев с бубнами. Ну будет стартовать джоб в разное время всегда, почему бы и нет. Главное же - непрерывно.
ВБ
Второй джоб, который будет следить за первым, не нужен. Т.к. ничто не мешает сразу в нём же запускать то, что выполнялось бы в первом. Только частота запуска уменьшается с 1 часа до 1 минуты (например). Если нравятся пляски с бубнами, то можно и проверки навесить, когда там в предыдущий раз джоб стартовал, начало часа ещё или уже конец и т.д.