скала, акторы и фьючеры
Apr. 9th, 2015 11:10 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
xacidя щетаю это надо увековечить (из сегодняшнего чата):
there are couple of tests in Jenkins failing due too long login it seems.
sometimes that login seems to take ~20 sec.
почему так получилось? блокирующие операции в акторах и при этом полное непонимание того как работают акторы в скале и тд. предложения разнести блокирующие и неблокирующие операции на разные пулы потоков, вызвало опять таки полное непонимание вопроса, хотя на самом деле это сделать было бы проще пареной репы. слова же о том что им акторы вообще не нужны в таких количествах, и для бизнес-логики лучше использовать композицию фьючеров, а акторы оставить только в тех немногих местах где нужно контроллировать некий уникальный ресурс (коннекшен, причем в любую сторону - от юзера, например, или в базу данных) привели в итоге к увольнению ...
причем я им подробнейшим образом раз десять все это говорил и объяснял. показывал конкретные проблемы причем в их же собственных тестах. особый садизм был в том что тесты падали только у меня - у них же все работало хорошо (по крайней мере по их словам). под словом "они" я имею ввиду трех людей (не буду естественно называть). в принципе они не плохие ребята только вот немного не понимают "вот этого вот". хотя на первый взгляд вроде бы квалифицированные люди. у них идея фикс что "всё можно и нужно сделать на одних только акторах". вот за это я акторы и не люблю :( но там где нужен актор там конечно лучше сделать актора. главное не злоупотреблять. но идиотизм здесь в том что акторы кажутся настолько простыми для понимания и использования (что на самом деле конечно же далеко не так!) что в итоге и приводит к подобным вот проблемам.
забавно еще то что в тех, опять таки достаточно редких, случаях где вот как раз на самом деле действительно было бы правильно взять актор в одном единственном числе и в нем считать какую нибудь сложную статистику которая интересна всем пользователям и при этом не зависит от того кто смотрит и при этом просто можно апдейтить эту статистику сообщениями по мере поступления новых данных - вот там как раз наоборот они создают каждому пользователю и на каждый его отдельный запрос нового актора и в нем считают для пользователя одну и ту же самую по сути статистику запросами в базу данных - вот это самый показательный мне кажется пример.
при этом мой код им не нравился :) при этом я говорил что код то мы сделаем в итоге как нужно, давайте сначала все таки вот эти вот проблемы исправим. помню вопрос главного по этим вопросам чувака из числа этих трех (на самом деле там так - есть два чувака которые вообще ничего там по сути не делают а только формально там руководят, а есть один чувак который типа взялся делать всё сам - в основном тупит он, а эти двое даже не знаю - видимо просто не хотят вмешиваться или еще какие у них там проблемы, видимо им похуй просто) ну так вот - спрашивает меня глядя в мой код:
"а зачем нужен DBActor? он же ничего не делает! он же просто выполняет запросы и всё!"
я говорю - ну да конечно, все правильно, запросы выполняет. а что он еще делать должен? он выполняет запросы в своем отдельном специальном пуле потоков. вот что он делает. а другие акторы - в другом пуле потоков работают и при этом уже запросов (то есть блокирующих операций) не выполняют. однако его это совершенно не убедило. в его понимании актор это какая-то бизнес-логика, а если актор типа никакой бизнес-логики не несет а просто выполняет функции которые ему в сообщении присылают и отсылает назад результат - то такой актор типа не нужен на самом деле. при этом создается миллион других разных акторов (вместо большинства из них могла бы быть простая монадическая функция с фьючером в результате) и потом композятся эти все акторы между собой через блядь блокирующее ожидание ответа одним актором от другого. при этом опять таки блядь они не понимают что по сути блокируют поток! то есть мало того что он (этот чувак который спрашивал) смешивает в одном пуле потоков блокирующие и не блокирующие операции в акторах, так он еще сам создает в своих же акторах свои же собственные блокирующие операции там где они вообще не нужны и можно было бы все сделать без блокировки и ожидания (а в монадических функциях все вообще простым for или в крайнем случае аппликативом композится чудесно). но нет же!
хорошо что я не стал работать там фулл-тайм, и есть на самом деле еще чем пока заниматься фуллтайм кроме них :)
there are couple of tests in Jenkins failing due too long login it seems.
sometimes that login seems to take ~20 sec.
почему так получилось? блокирующие операции в акторах и при этом полное непонимание того как работают акторы в скале и тд. предложения разнести блокирующие и неблокирующие операции на разные пулы потоков, вызвало опять таки полное непонимание вопроса, хотя на самом деле это сделать было бы проще пареной репы. слова же о том что им акторы вообще не нужны в таких количествах, и для бизнес-логики лучше использовать композицию фьючеров, а акторы оставить только в тех немногих местах где нужно контроллировать некий уникальный ресурс (коннекшен, причем в любую сторону - от юзера, например, или в базу данных) привели в итоге к увольнению ...
причем я им подробнейшим образом раз десять все это говорил и объяснял. показывал конкретные проблемы причем в их же собственных тестах. особый садизм был в том что тесты падали только у меня - у них же все работало хорошо (по крайней мере по их словам). под словом "они" я имею ввиду трех людей (не буду естественно называть). в принципе они не плохие ребята только вот немного не понимают "вот этого вот". хотя на первый взгляд вроде бы квалифицированные люди. у них идея фикс что "всё можно и нужно сделать на одних только акторах". вот за это я акторы и не люблю :( но там где нужен актор там конечно лучше сделать актора. главное не злоупотреблять. но идиотизм здесь в том что акторы кажутся настолько простыми для понимания и использования (что на самом деле конечно же далеко не так!) что в итоге и приводит к подобным вот проблемам.
забавно еще то что в тех, опять таки достаточно редких, случаях где вот как раз на самом деле действительно было бы правильно взять актор в одном единственном числе и в нем считать какую нибудь сложную статистику которая интересна всем пользователям и при этом не зависит от того кто смотрит и при этом просто можно апдейтить эту статистику сообщениями по мере поступления новых данных - вот там как раз наоборот они создают каждому пользователю и на каждый его отдельный запрос нового актора и в нем считают для пользователя одну и ту же самую по сути статистику запросами в базу данных - вот это самый показательный мне кажется пример.
при этом мой код им не нравился :) при этом я говорил что код то мы сделаем в итоге как нужно, давайте сначала все таки вот эти вот проблемы исправим. помню вопрос главного по этим вопросам чувака из числа этих трех (на самом деле там так - есть два чувака которые вообще ничего там по сути не делают а только формально там руководят, а есть один чувак который типа взялся делать всё сам - в основном тупит он, а эти двое даже не знаю - видимо просто не хотят вмешиваться или еще какие у них там проблемы, видимо им похуй просто) ну так вот - спрашивает меня глядя в мой код:
"а зачем нужен DBActor? он же ничего не делает! он же просто выполняет запросы и всё!"
я говорю - ну да конечно, все правильно, запросы выполняет. а что он еще делать должен? он выполняет запросы в своем отдельном специальном пуле потоков. вот что он делает. а другие акторы - в другом пуле потоков работают и при этом уже запросов (то есть блокирующих операций) не выполняют. однако его это совершенно не убедило. в его понимании актор это какая-то бизнес-логика, а если актор типа никакой бизнес-логики не несет а просто выполняет функции которые ему в сообщении присылают и отсылает назад результат - то такой актор типа не нужен на самом деле. при этом создается миллион других разных акторов (вместо большинства из них могла бы быть простая монадическая функция с фьючером в результате) и потом композятся эти все акторы между собой через блядь блокирующее ожидание ответа одним актором от другого. при этом опять таки блядь они не понимают что по сути блокируют поток! то есть мало того что он (этот чувак который спрашивал) смешивает в одном пуле потоков блокирующие и не блокирующие операции в акторах, так он еще сам создает в своих же акторах свои же собственные блокирующие операции там где они вообще не нужны и можно было бы все сделать без блокировки и ожидания (а в монадических функциях все вообще простым for или в крайнем случае аппликативом композится чудесно). но нет же!
хорошо что я не стал работать там фулл-тайм, и есть на самом деле еще чем пока заниматься фуллтайм кроме них :)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-09-12 01:41 am (UTC)С днём Рождения! Будьте Собой! ;) Богом! Частью Его, аватарой.
no subject
Date: 2015-09-12 11:04 pm (UTC)