Size: a a a

Scala User Group

2020 February 16

λ

λoλdog in Scala User Group
Sergey Rublev
уже опробовал PR, это мне починило нативную сборку ZIO с GraalVM, запуск бинарника падал из-за scala-reflect
Нужно было просто инициализацию в билд таиме сделать
источник

SR

Sergey Rublev in Scala User Group
и так в билд тайме
источник

λ

λoλdog in Scala User Group
Тогда не должно было стрелять
источник

λ

λoλdog in Scala User Group
А что именно кидалось?
источник

SR

Sergey Rublev in Scala User Group
источник

λ

λoλdog in Scala User Group
Ну это точно решается через initialize-at-build-time
источник

SR

Sergey Rublev in Scala User Group
λoλdog
Ну это точно решается через initialize-at-build-time
ну хер знает, флаги стоят, в любом случае с PR-ом безо всяких проблем сходу все завелось, что в любом случае вносит положительный импакт
источник

NP

Nikita Pedorich in Scala User Group
Привет! Пытаюсь перевезти небольшое API на akka-http на использование cats IO, помогите разобраться в том как это взаимодействует на уровне тредов. Вот у акки есть дока как правильно делать блокирующие операции https://doc.akka.io/docs/akka-http/current/handling-blocking-operations-in-akka-http-routes.html, так и делаю - создаю отдельный ContextShift с пулом тредов для блокирующих операций, мои сервисы возвращают IO. Потом делаю marshaller, как тут https://github.com/holidaycheck/easy-akka-http/blob/master/easy-akka-marshalling/src/main/scala/com/holidaycheck/akka/http/FMarshaller.scala#L23 и этот ContextShift передаю туда. Но внутри этот marshaller превращает IO в футуру, а футуры в акке резолвятся на том же ExecutionContext что и Actor https://github.com/akka/akka-http/blob/master/akka-http/src/main/scala/akka/http/scaladsl/server/directives/FutureDirectives.scala#L36, так не значит ли это, что в итоге тред который обработал HTTP запрос и передал его сервису который заспавнил IO в другом треде ждет его теперь и выходит что он всё равно заблокирован, только теперь не напрямую а ожиданием другого треда?
Я вижу вот в ZIO тоже примерно такой трансформ https://github.com/jczuchnowski/zio-akka-slick-app/blob/master/src/main/scala/example/interop/akka/ZioSupport.scala#L13
источник

ЮБ

Юрий Бадальянц in Scala User Group
Nikita Pedorich
Привет! Пытаюсь перевезти небольшое API на akka-http на использование cats IO, помогите разобраться в том как это взаимодействует на уровне тредов. Вот у акки есть дока как правильно делать блокирующие операции https://doc.akka.io/docs/akka-http/current/handling-blocking-operations-in-akka-http-routes.html, так и делаю - создаю отдельный ContextShift с пулом тредов для блокирующих операций, мои сервисы возвращают IO. Потом делаю marshaller, как тут https://github.com/holidaycheck/easy-akka-http/blob/master/easy-akka-marshalling/src/main/scala/com/holidaycheck/akka/http/FMarshaller.scala#L23 и этот ContextShift передаю туда. Но внутри этот marshaller превращает IO в футуру, а футуры в акке резолвятся на том же ExecutionContext что и Actor https://github.com/akka/akka-http/blob/master/akka-http/src/main/scala/akka/http/scaladsl/server/directives/FutureDirectives.scala#L36, так не значит ли это, что в итоге тред который обработал HTTP запрос и передал его сервису который заспавнил IO в другом треде ждет его теперь и выходит что он всё равно заблокирован, только теперь не напрямую а ожиданием другого треда?
Я вижу вот в ZIO тоже примерно такой трансформ https://github.com/jczuchnowski/zio-akka-slick-app/blob/master/src/main/scala/example/interop/akka/ZioSupport.scala#L13
В котах с недавнего времени есть Blocker. Это обёртка над пулом, чтобы отличить его от обычного тред пула. Но это так, просто полезное знание.
По твоему вопросу - после блокирующей операции ты же делаешь что-то с результатом? И это делается на обычном тред пуле. Тебе в акку нужно отдать ио, которое уже на обычном тред пуле исполняется.
Но и в целом это не важно - когда ты делаешь unsafeToFuture (ты ведь так планируешь ио во фьючи перегонять?) оно прибито к тому тред пулу, на котором ты ио планировал запускать. То, что в акке требуется тред пул - это уже для всяких других операций на фьюче.
источник

ЮБ

Юрий Бадальянц in Scala User Group
Фьючи для каждого map и flatMap требует пула
источник

NP

Nikita Pedorich in Scala User Group
Юрий Бадальянц
В котах с недавнего времени есть Blocker. Это обёртка над пулом, чтобы отличить его от обычного тред пула. Но это так, просто полезное знание.
По твоему вопросу - после блокирующей операции ты же делаешь что-то с результатом? И это делается на обычном тред пуле. Тебе в акку нужно отдать ио, которое уже на обычном тред пуле исполняется.
Но и в целом это не важно - когда ты делаешь unsafeToFuture (ты ведь так планируешь ио во фьючи перегонять?) оно прибито к тому тред пулу, на котором ты ио планировал запускать. То, что в акке требуется тред пул - это уже для всяких других операций на фьюче.
Ну у меня работа с базой, hbase. Да, результат блокирующей операции возвращается как http ответ.  Вот я обернул hbase операцию в IO, сделал shift на отдельный тред и отдаю это акке. Акка превращает IO в Future и ждет выполнения этой future, так? То есть в итоге и акка и тот другой тред заблокированы?
источник

SA

Sergey Alaev in Scala User Group
Nikita Pedorich
Привет! Пытаюсь перевезти небольшое API на akka-http на использование cats IO, помогите разобраться в том как это взаимодействует на уровне тредов. Вот у акки есть дока как правильно делать блокирующие операции https://doc.akka.io/docs/akka-http/current/handling-blocking-operations-in-akka-http-routes.html, так и делаю - создаю отдельный ContextShift с пулом тредов для блокирующих операций, мои сервисы возвращают IO. Потом делаю marshaller, как тут https://github.com/holidaycheck/easy-akka-http/blob/master/easy-akka-marshalling/src/main/scala/com/holidaycheck/akka/http/FMarshaller.scala#L23 и этот ContextShift передаю туда. Но внутри этот marshaller превращает IO в футуру, а футуры в акке резолвятся на том же ExecutionContext что и Actor https://github.com/akka/akka-http/blob/master/akka-http/src/main/scala/akka/http/scaladsl/server/directives/FutureDirectives.scala#L36, так не значит ли это, что в итоге тред который обработал HTTP запрос и передал его сервису который заспавнил IO в другом треде ждет его теперь и выходит что он всё равно заблокирован, только теперь не напрямую а ожиданием другого треда?
Я вижу вот в ZIO тоже примерно такой трансформ https://github.com/jczuchnowski/zio-akka-slick-app/blob/master/src/main/scala/example/interop/akka/ZioSupport.scala#L13
Не совсем так.
ContextShift должен быть один на приложение исключительно для исполнения неблокирующей IO-монады, для блокирующих операций нужно создавать ExecutionContext и далее ContextShift.evalOn
источник

ЮБ

Юрий Бадальянц in Scala User Group
Nikita Pedorich
Ну у меня работа с базой, hbase. Да, результат блокирующей операции возвращается как http ответ.  Вот я обернул hbase операцию в IO, сделал shift на отдельный тред и отдаю это акке. Акка превращает IO в Future и ждет выполнения этой future, так? То есть в итоге и акка и тот другой тред заблокированы?
Покажи код, так сложно сказать
источник

ЮБ

Юрий Бадальянц in Scala User Group
Все зависит от того, как конкретно написано
источник

ЮБ

Юрий Бадальянц in Scala User Group
Скорее всего ничего не блокируется
источник

KS

Kirill Shelopugin in Scala User Group
Sergey Alaev
Не совсем так.
ContextShift должен быть один на приложение исключительно для исполнения неблокирующей IO-монады, для блокирующих операций нужно создавать ExecutionContext и далее ContextShift.evalOn
Кому должен?
источник

SA

Sergey Alaev in Scala User Group
Kirill Shelopugin
Кому должен?
Должен Шелопугину поднять самооценку
источник

ЮБ

Юрий Бадальянц in Scala User Group
Ещё - заверни именно операции с hbase в отдельный блокирующий пул, а всё остальное ио делай на основном пуле.
источник

KS

Kirill Shelopugin in Scala User Group
Important: this is NOT a type class, meaning that there is no coherence restriction
источник

KS

Kirill Shelopugin in Scala User Group
ContextShift is the pure equivalent to:

Scala’s ExecutionContext
источник