Comments 10
Play действительно прекрасен.
Но позвольте пару замечаний.
1. Все элементы RSS item опциональны. Так что парсить надо несколько хитрее. Для примера: я недавно сам написал парсер RSS, можете воспользоваться. В тестах есть примеры использования. Все парсеры возвращают Validation, так что если будут ошибки в форматировании RSS их можно залогировать.
2. Зачем вам везде `try`, да еще и с просто `throw e`? Это же просто мусор в коде. Да и `try` с `case e: Throwable => ...` — тоже плохая идея. Пользуйтесь лучше Try — он проверяет что стоит ловить, а что нельзя.
3. Оборачивать в `Future` блокирующий код не очень полезно в данном случае. У вас все равно целый поток будет занят как с `Action`, так и с `Action.async`. В случае с MongoDB надо пользоваться Future чуть хитрее. Воспользуйтесь Reactive MongoDB. Он возвращает Future при операциях и позволяет писать действительно не блокирующий код.
Заодно он избавит от ужаса с ручным разбором результата (не надо писать `as[String]` и тому подобное). Код станет и короче и безопаснее.
Вот пример использования.
Но позвольте пару замечаний.
1. Все элементы RSS item опциональны. Так что парсить надо несколько хитрее. Для примера: я недавно сам написал парсер RSS, можете воспользоваться. В тестах есть примеры использования. Все парсеры возвращают Validation, так что если будут ошибки в форматировании RSS их можно залогировать.
2. Зачем вам везде `try`, да еще и с просто `throw e`? Это же просто мусор в коде. Да и `try` с `case e: Throwable => ...` — тоже плохая идея. Пользуйтесь лучше Try — он проверяет что стоит ловить, а что нельзя.
3. Оборачивать в `Future` блокирующий код не очень полезно в данном случае. У вас все равно целый поток будет занят как с `Action`, так и с `Action.async`. В случае с MongoDB надо пользоваться Future чуть хитрее. Воспользуйтесь Reactive MongoDB. Он возвращает Future при операциях и позволяет писать действительно не блокирующий код.
Заодно он избавит от ужаса с ручным разбором результата (не надо писать `as[String]` и тому подобное). Код станет и короче и безопаснее.
Вот пример использования.
По поводу RSS я особо не заморачивался. В исключительно образовательных целях на первый раз сойдет. Само собой, в более серьезных проектах это дело надо валидировать.
На Try посмотрю, спасибо за линк. Для себя скалку открыл совсем недавно. И это прекрасно, так как столько много еще предстоит узнать.
А по поводу Future — рооовно над вашим коментарием как раз есть абзац про Future, блокировки и ReactiveMongo)
На Try посмотрю, спасибо за линк. Для себя скалку открыл совсем недавно. И это прекрасно, так как столько много еще предстоит узнать.
А по поводу Future — рооовно над вашим коментарием как раз есть абзац про Future, блокировки и ReactiveMongo)
Действительно пропустил упоминание Reactive Mongo в статье. Но суть не в этом, а в том как в статье используется Future — там нет выигрыша от параллельности, а только дополнительные затраты (хоть и не большие) связанные с Future.
Ну как я понял из доков Play, при использовании Future основной поток выполнения все же блокироваться не будет, что позволит обслуживать остальные запросы.
The web client will be blocked while waiting for the response, but nothing will be blocked on the server, and server resources can be used to serve other clients.
Действительно, только вот поток не может взяться ниоткуда.
При большом количестве таких задач мы либо плавно возвращаемся в мир thread per client либо будем очень долго ждать пока все эти операции пройдут на соответсвующем ExecutionContext.
При большом количестве таких задач мы либо плавно возвращаемся в мир thread per client либо будем очень долго ждать пока все эти операции пройдут на соответсвующем ExecutionContext.
Ни в коем случае не спорил о необходимости использования асинхронных драйверов, однако странным кажется заявление о том, что Future является исключительно затратным по производительности способом при работе с sync IO. Все же блокировка в пределах указанного контекста не является смертельной при малом количестве задач. При этом, повторюсь, основной поток освободится.
Future при работе с синхронным IO — сложная тема.
Если нагрузки есть, то очевидны проблемы, если нет, то и крутиться такой веб-сервис может на одноядерной vps. А ExecutionContext по умолчанию, насколько помню, использует удвоенное число потоков по отношению к ядрам. 2 одновременных запроса и все потоки блокированы.
Так что оборачивать блокирующее IO в Future можно, но для этого надо использовать отдельный ExecutionContext. А такие трюки в контроллере делать не стоит, надо выносить отдельно, фактически оборачивая блокирующий функционал неблокирующей оберткой.
По поводу основного потока: если в play есть основной поток для обработки соединения, то да, оборачивать в Future имеет смысл, если же обработка многопоточная на основании того же defaultContext, то все равно будет блокирован 1 поток. Я предполагал второй вариант, но может я и не прав — не смог быстро найти в коде.
Если нагрузки есть, то очевидны проблемы, если нет, то и крутиться такой веб-сервис может на одноядерной vps. А ExecutionContext по умолчанию, насколько помню, использует удвоенное число потоков по отношению к ядрам. 2 одновременных запроса и все потоки блокированы.
Так что оборачивать блокирующее IO в Future можно, но для этого надо использовать отдельный ExecutionContext. А такие трюки в контроллере делать не стоит, надо выносить отдельно, фактически оборачивая блокирующий функционал неблокирующей оберткой.
По поводу основного потока: если в play есть основной поток для обработки соединения, то да, оборачивать в Future имеет смысл, если же обработка многопоточная на основании того же defaultContext, то все равно будет блокирован 1 поток. Я предполагал второй вариант, но может я и не прав — не смог быстро найти в коде.
По какой причине playframework не так популярен, как всякие модные штуки?
Не зря же его берут на вооружение банки, а разрабатывают в академических кругах.
Не зря же его берут на вооружение банки, а разрабатывают в академических кругах.
В этой нише веба доминирует спринг. Это если рассматривать Play как Java фреймворк, каковым он тоже является.
А касаемо скалки… К сожалению, относительный процент спроса на Scala в продакшене чрезвычайно мал, даже не смотря на крупный рост за последние годы. Отсюда и небольшое коммьюнити и экосистема в целом. Все это, конечно, относительно тех же Java/Spring.
Меня самого это крайне печалит, так как субъективно Java ну очень уж многословна, а на том же hh вакансий по скале практически нет. Одним из выходов для себя вижу обоснование перед руководством перехода на новый язык и платформу. Благо, по этому поводу есть что сказать.
А если под модными штучками подразумевается, например, нода, то тут дело в пороге вхождения. Для того, чтобы начать писать там код, вам не придется углубляться в недры sbt и т.п. Это как преимущество, так и недостаток технологии.
А касаемо скалки… К сожалению, относительный процент спроса на Scala в продакшене чрезвычайно мал, даже не смотря на крупный рост за последние годы. Отсюда и небольшое коммьюнити и экосистема в целом. Все это, конечно, относительно тех же Java/Spring.
Меня самого это крайне печалит, так как субъективно Java ну очень уж многословна, а на том же hh вакансий по скале практически нет. Одним из выходов для себя вижу обоснование перед руководством перехода на новый язык и платформу. Благо, по этому поводу есть что сказать.
А если под модными штучками подразумевается, например, нода, то тут дело в пороге вхождения. Для того, чтобы начать писать там код, вам не придется углубляться в недры sbt и т.п. Это как преимущество, так и недостаток технологии.
Возможно он появился совсем недавно, play 2 версии совершенно другой фреймворк. Они начали с чистого листа. К тому же немного страдает поддержка Java для фреймворка. А вообще Spring оч популярен, но не является модной штучкой. Скорее это понятие не для Java мира.
Sign up to leave a comment.
Играем в RSS с PlayFramework 2.2 и Scala