Спасибо вам за это интервью. Как и многие, я начинал свой путь в освоении ассемблера с его книг. Хотел как-то написать ему письмо и поблагодарить за его книги, но подумал, что будет довольно глупо отвлекать занятого человека от дел :) А теперь вот уже поздно. RIP KPNC.
Это не проблема, т.к. файлов на выходе у программ считанные единицы. А вот объектов, которые используются в процессе генерации этих файов — миллиарды. И память для них утекает в каждом первом приложении. В нынешнем мире достаточно прибить процесс и перезапустить его, вуаля — проблема решена. Кажется, что рядом с персистентной моделью памяти в любом случае должна быть какая-то неперсистентная, которую можно безболезненно вайпнуть и не потерять действительнно важные объекты. Либо нужна другая модель виртуальной машины, такая, которая бы by design не допускала утечек памяти. Например, если разделить память на 2 части: персистентные данные (аналог файлов) и неперсистентные (аналог оперативной памяти), то можно попробовать сделать что-то вроде этого:
with (use persistentData) {
// Код для обработки каких-то данных, который ограничен возможностями по передаче ссылок
// на созданные внутри объекты. Все объекты в рамках этого кода могут (и должны) быть удалены
// автоматически, как только обработка завершена.
}
На входе и на выходе такого куска кода — объект персистентных данных. Созданные динамические объекты не будут жить дольше, чем живёт этот код, ссылки на них нельзя передать в другие места, не делая объекты персистентными. В общем-то схема получается аналогичная текущей. Правда непонятно тогда, в чём выгода. Можно лишь удалить код сериализации/десериализации, вместо этого пользоваться объектами как есть, иногда маркируя их соответствующими атрибутами.
А что предполагается делать с приложениями, у которых просто течёт память? Согласно персистентной модели, приложение запускается один раз и на всю жизнь. Пусть это какой-нибудь Office, в нём пользователь создаёт какие-то документы. Этими документами он обменивается с другими приложениями/устройствами. Но вот память течёт и течёт. Можно ли будет остановить это и не потерять созданные документы? Как это будет выглядеть с точки зрения пользователя?
Мой опыт показывает, что деплоить war намного менее удобно, чем запускать jar со встроенным сервлет-контейнером. По пунктам.
1. Редеплой часто бывает не production-ready. Например, в jboss as в своё время редеплой хоть и работал, но периодически глючил.
2. Деплой через cargo — медленный и неудобный для разработки, а безопасность его под вопросом в продакшене. Медленный — потому что копируются все ресурсы приложения, а потом вся эта штука разворачивается контейнером. При использовании встроенного сервлет-контейнера достаточно лишь перезапустить процесс. Ничего копировать и распаковывать не нужно. Это что касается окружения разработки. А чтобы не велосипедить на скриптах при деплое в продакшене, можно сделать deb-пакет, например, или использовать контейнеры. Дополнительный плюс такого подхода будет в том, что не придётся долго рассказывать админам, как выполняется деплой. Обновил пакет — и всё работает. Что же касается безопасности деплоя через сокет в продакшене, достаточно отметить, что были эксплоиты для различных серверов приложений, которые эксплуатировали дырки в админках. Конечно, эти порты наружу не будут открыты, но в случае эмбеддед сервера этой проблемы вообще нет.
3. Не в курсе про томкат, может быть там все действительно хорошо с zero downtime, но я бы поостерёгся редеплоить приложения в продакшене (см первый пункт).
Сравнить скорость cargo и ембеддед можно легко, если есть в наличии проект, war которого занимает мегабайт 70. cargo будет деплоить эту штуку сильно дольше, чем просто запустится новый java-процесс. А высокая скорость рестарта при разработке — высокая производительность программистов, то есть наше всё.
Оказалось, что pytest-xdist конфликтует с Allure Pytest Adaptor. Начали разбираться, проблема известная, уже длительное время обсуждается и не решена. Также готового решения для наследовании тестовых данных по локалям найти не удалось,
Посмотрел на Vertx-Sync, там написано, что оно работает на базе Quasar, который, как я понимаю, использует аналогичные jcoro механизмы. Ну то есть там тоже есть восстанавливаемый контекст выполнения и инструментирование байт-кода. Так что даже не знаю, что проще — взять одну jcoro или пробовать vertx-sync, который зависит от quasar и vertx, которые сами по себе не маленькие :)
Кажется, это те же коллбеки, записанные иначе (заранее сохранённые в отдельную переменную и потом использованные). Но дело даже не в том, что коллбеки плохи сами по себе. Проблема в неудобствах, которые возникают, когда нам нужно результат одной операции передать в следующую. Плюс, надо как-то уметь обрабатывать ошибки. А если писать синхронный код, таких проблем не возникает — всё просто и понятно. В этом суть подхода.
Круто! Я не решился на статический анализ, решил для начала размечать аннотациями вручную. Статический анализ действительно хорошо работает в этом месте?
Если писать сервер, то этот ужасный код будет только в самом верху стека обработки запроса, далее писать код можно обычными методами, только следя за аннотациями на точках восстановления. А все асинхронные операции достаточно один раз обернуть в сопрограммы и положить в утилитный класс, и больше его не трогать, а пользоваться ими как синхронными вызовами. См пример
Это не проблема, т.к. файлов на выходе у программ считанные единицы. А вот объектов, которые используются в процессе генерации этих файов — миллиарды. И память для них утекает в каждом первом приложении. В нынешнем мире достаточно прибить процесс и перезапустить его, вуаля — проблема решена. Кажется, что рядом с персистентной моделью памяти в любом случае должна быть какая-то неперсистентная, которую можно безболезненно вайпнуть и не потерять действительнно важные объекты. Либо нужна другая модель виртуальной машины, такая, которая бы by design не допускала утечек памяти. Например, если разделить память на 2 части: персистентные данные (аналог файлов) и неперсистентные (аналог оперативной памяти), то можно попробовать сделать что-то вроде этого:
На входе и на выходе такого куска кода — объект персистентных данных. Созданные динамические объекты не будут жить дольше, чем живёт этот код, ссылки на них нельзя передать в другие места, не делая объекты персистентными. В общем-то схема получается аналогичная текущей. Правда непонятно тогда, в чём выгода. Можно лишь удалить код сериализации/десериализации, вместо этого пользоваться объектами как есть, иногда маркируя их соответствующими атрибутами.
(на правах рекламы)
А диагностировать неудачный коннект можно было ещё попробовать с помощью dtrace.
1. Редеплой часто бывает не production-ready. Например, в jboss as в своё время редеплой хоть и работал, но периодически глючил.
2. Деплой через cargo — медленный и неудобный для разработки, а безопасность его под вопросом в продакшене. Медленный — потому что копируются все ресурсы приложения, а потом вся эта штука разворачивается контейнером. При использовании встроенного сервлет-контейнера достаточно лишь перезапустить процесс. Ничего копировать и распаковывать не нужно. Это что касается окружения разработки. А чтобы не велосипедить на скриптах при деплое в продакшене, можно сделать deb-пакет, например, или использовать контейнеры. Дополнительный плюс такого подхода будет в том, что не придётся долго рассказывать админам, как выполняется деплой. Обновил пакет — и всё работает. Что же касается безопасности деплоя через сокет в продакшене, достаточно отметить, что были эксплоиты для различных серверов приложений, которые эксплуатировали дырки в админках. Конечно, эти порты наружу не будут открыты, но в случае эмбеддед сервера этой проблемы вообще нет.
3. Не в курсе про томкат, может быть там все действительно хорошо с zero downtime, но я бы поостерёгся редеплоить приложения в продакшене (см первый пункт).
Сравнить скорость cargo и ембеддед можно легко, если есть в наличии проект, war которого занимает мегабайт 70. cargo будет деплоить эту штуку сильно дольше, чем просто запустится новый java-процесс. А высокая скорость рестарта при разработке — высокая производительность программистов, то есть наше всё.
Мой коллега pupssman пофиксил эту штуку и даже предложил пулл реквест: github.com/allure-framework/allure-python/pull/80
Попробуйте )