судя по всему он сам верит во все, что пишет

¯\_(ツ)_/¯

да, и маскирует это за толщиной

многоходовочка (с)

наверное он имел ввиду сиквентальный какой-нибудь

Всмысле последовательный?

Невероятно звучит, если честно. Основной контракт актора, каким бы он ни был - отсутствие конкурентности внутри, вызов же будет через проксю. Разные потоки - да, одновременно - едва ли.

Untyped акторов да, там же mailbox. а насчёт TypedActor не уверен, т.е. прокся синхронизирует вызов getUserName ? не знал, надо проверить.

Untyped акторов да, там же mailbox. а насчёт TypedActor не уверен, т.е. прокся синхронизирует вызов getUserName ? не знал, надо проверить.

а иначе зачем бы они вообще были надо?

А зачем тогда вообще акторы?

ну вот собственно сообщество и озвучило мои мысли

правда когда я приходил в чатик у меня были другие ожидания от сообщества - умные ребята, обсуждение новостей и статей на предметную область

и все это конечно здесь есть, но столько трололо, и так шума/непонимания много, зачем еще намеренного добавлять

Для тех кто в танке, там даже ноту вверху прикрепили) Note Just as with regular Akka Actors, Typed Actors process one call at a time.

и все это конечно здесь есть, но столько трололо, и так шума/непонимания много, зачем еще намеренного добавлять

Все мы живые люди

это будет не в акторах

конечно же я имел ввиду Актора как место в памяти (а не поток исполнения), что в future.onComplete ты можешь поменять переменную внутри актора

конечно же я имел ввиду Актора как место в памяти (а не поток исполнения), что в future.onComplete ты можешь поменять переменную внутри актора

А ты смешной

А ты смешной

ну давай поясни тогда свои мысли теперь, без шуток

за базар поясни

Для тех кто в танке, там даже ноту вверху прикрепили) Note Just as with regular Akka Actors, Typed Actors process one call at a time.

Блин точно. Значит у меня что то другое. Отсюда вопрос, как более православно делать запрос с возвратом результата ? через future, ask или через Untyped + RequestMsg ResponseMsg ?

если ты вне системы то ask это нормально

ну давай поясни тогда свои мысли теперь, без шуток

То, что ты можешь обратиться к обьекту и что-то с ним делать - это прекрасно, но это собственно часть возможностей языка. К библиотеке это никакого отношения не имеет.

если внутри то tell, но не забудь про таймауты всякие

Мне тоже кажется что вторым способом оптимальнее, но многословнее

если ты вне системы то ask это нормально

Вне системы , что имеется ввиду ? Всё же в акторах происходит

Поиск работы здесь не возбраняется проводить?)

Вне системы , что имеется ввиду ? Всё же в акторах происходит

Денис слишком кратко высказался. Его мысль заключалась в том, что если ты реализуешь пример из доков "Пинг-Понг" - тебе стоит использовать семантику только посылки сообщений, а не request-response. Когда ты отправил пинг, тот может ответить через sender() ! Pong. Если же источник соощения вне актора, то sender ! Pong уйдет в дедлеттерс

Поиск работы здесь не возбраняется проводить?)

адекватный и без спама можно

Денис слишком кратко высказался. Его мысль заключалась в том, что если ты реализуешь пример из доков "Пинг-Понг" - тебе стоит использовать семантику только посылки сообщений, а не request-response. Когда ты отправил пинг, тот может ответить через sender() ! Pong. Если же источник соощения вне актора, то sender ! Pong уйдет в дедлеттерс

его мысль заключалась в том, что request-response вполне норм использовать actor-actor, но через tell и scheduled timeout

зачем вы рассуждаете о его мыслях

зачем вы рассуждаете о его мыслях

?

зачем вы рассуждаете о его мыслях

Он уважаемый человек, все так делают, посмотри курс школьной литературы, там постоянно рассуждают о чужих мыслях

Он уважаемый человек, все так делают, посмотри курс школьной литературы, там постоянно рассуждают о чужих мыслях

таки хороший пример

все учителя литературы и гиды в музее

мысли человека можно обсудить, если его нет где-то рядом) я так считаю

а вы в чатике можете и спросить прямо, что он имел ввиду

его мысль заключалась в том, что request-response вполне норм использовать actor-actor, но через tell и scheduled timeout

у телла нет таймаута

мысли человека можно обсудить, если его нет где-то рядом) я так считаю

в чатике все находятся в промежуточном состоянии между "рядом и есть"

То, что ты можешь обратиться к обьекту и что-то с ним делать - это прекрасно, но это собственно часть возможностей языка. К библиотеке это никакого отношения не имеет.

ок, я понял, моя ошибка - не достаточно точно изначально выразился. ход мыслей был такой: 1. Человек говорит что у него внутри тайпед акторов конкуретный доступ и он переделывает на обычные акторы 2. Контракт любых акторов - последовательная обработка сообщений - очень маловероятно что создатели Akka тупанули и в тайпед акторах (любой версии) нарушили контракт акторов 3. Вывод - скорее всего человек делает что-то не так в тайпед акторах, и продолжит делать ту же ошибку в обычных акторах, поэтому я привожу пример с неправильным обращением с обычным актором - использовать контекст актора из future.onComplete

у телла нет таймаута

именно поэтому нужно скедулить себе сообщение, чтобы не ждать вечно

а вы в чатике можете и спросить прямо, что он имел ввиду

зачем? чатики не для этого

тогда скину, когда сообщения перестанут бежать так быстро :D

именно поэтому нужно скедулить себе сообщение, чтобы не ждать вечно

вопрос, а нужно ли его ждать?

именно поэтому нужно скедулить себе сообщение, чтобы не ждать вечно

опять таки это ведет к брейку "реквест-респонз", потому что ты ручками начинаешь отслеживать флаги. и когда тебе понг придет - без ask это означает, что ты понятия не имеешь на какой пинг он пришел и вобще пришел ли он на пинг

вопрос, а нужно ли его ждать?

в большинстве ситуаций, где естественнен request-response, спрашивающий сильно зависит от ответа

дык request-response умеет и сам отвалится)

если про браузер говорить

опять таки это ведет к брейку "реквест-респонз", потому что ты ручками начинаешь отслеживать флаги. и когда тебе понг придет - без ask это означает, что ты понятия не имеешь на какой пинг он пришел и вобще пришел ли он на пинг

имеешь понятие, если оставишь себе идентифицирующую запрос информацию

дык request-response умеет и сам отвалится)

говорим о семантике

имеешь понятие, если оставишь себе идентифицирующую запрос информацию

симулировать конечно можно, но костыльно. телл не для симуляций, для чистых акторов епт, без сайд эффектов

дык request-response умеет и сам отвалится)

Актор A что-то хочет спросить у Актора B - как это сделать? ask или не ask?

Актор A что-то хочет спросить у Актора B - как это сделать? ask или не ask?

все зависит от контекста

симулировать конечно можно, но костыльно. телл не для симуляций, для чистых акторов епт, без сайд эффектов

Евангелие от Куна?

по мне так именно ask костыльно использовать для actor-actor

потому что в случае ask, если не ошибаюсь, реципиент будет ждать ответ от конкретного актора, в случае tell, он может делегировать ответ вдоль по системе

какие такие чистые акторы без сайд эффектов???

ок, я понял, моя ошибка - не достаточно точно изначально выразился. ход мыслей был такой: 1. Человек говорит что у него внутри тайпед акторов конкуретный доступ и он переделывает на обычные акторы 2. Контракт любых акторов - последовательная обработка сообщений - очень маловероятно что создатели Akka тупанули и в тайпед акторах (любой версии) нарушили контракт акторов 3. Вывод - скорее всего человек делает что-то не так в тайпед акторах, и продолжит делать ту же ошибку в обычных акторах, поэтому я привожу пример с неправильным обращением с обычным актором - использовать контекст актора из future.onComplete

опять как-то коряво совсем, причем тут правильное использование акторов? правильный посыл как раз в том, чтобы разделить, что является частью семантики акторов, а что нет. и когда ты делаешь future.oncomplete - это к акторам вобще никакого отношения не имеет

потому что в случае ask, если не ошибаюсь, реципиент будет ждать ответ от конкретного актора, в случае tell, он может делегировать ответ вдоль по системе

вот тут примерно и начинается акка-ад следить за такими цепочками мало удовольствия

давай за базар поясняй

как токсично, мне нравится, продолжай

опять как-то коряво совсем, причем тут правильное использование акторов? правильный посыл как раз в том, чтобы разделить, что является частью семантики акторов, а что нет. и когда ты делаешь future.oncomplete - это к акторам вобще никакого отношения не имеет

вот че ты докопался

по мне так именно ask костыльно использовать для actor-actor

если тебе нужна семантика - "реквест-респонз", ты так или иначе будешь реализовывать свой костыль вместо ask и оно будет куда костыльнее.

вот че ты докопался

лопатку дали, я и копаю)

вот тут примерно и начинается акка-ад следить за такими цепочками мало удовольствия

такой же ад как и в любых приложениях с очередями, т.е. никакого

вот тут примерно и начинается акка-ад следить за такими цепочками мало удовольствия

так блин, в них же вся фишка этой чеООПухи

давай за базар поясняй

Да все так, если actor-actor используй tell c timeout. Хочешь обратиться к актору не из актора используй ask.

ERROR: S client not available

но и как обычно it depends

Да все так, если actor-actor используй tell c timeout. Хочешь обратиться к актору не из актора используй ask.

но с телл+скедулед таймаут будет уже не реквест-респонз. несмотря на то, что при определенных условиях - очень похоже

а зачем делать tell с таймаутом если есть ask?

опять как-то коряво совсем, причем тут правильное использование акторов? правильный посыл как раз в том, чтобы разделить, что является частью семантики акторов, а что нет. и когда ты делаешь future.oncomplete - это к акторам вобще никакого отношения не имеет

я все понимаю что ты имеешь ввиду, я просто пытался из далека зайти, а этот пример для наглядности что ты можешь сломать актор модель фьючером изнутри, но в данном конкретном случае конечно надо было по другому строить диалог с человеком, ведь я не знал о его уровне осведомленности про технологии которые он использует

я все понимаю что ты имеешь ввиду, я просто пытался из далека зайти, а этот пример для наглядности что ты можешь сломать актор модель фьючером изнутри, но в данном конкретном случае конечно надо было по другому строить диалог с человеком, ведь я не знал о его уровне осведомленности про технологии которые он использует

так ведь ты и не сломаешь модель акторов своей футуркой. может сломаться только твоя программка, если она вдруг думает, что она является частью актора

потому что при ask у тебя создается прокси актор

а зачем делать tell с таймаутом если есть ask?

потому что есть разные шаблоны программирования. и есть те, которые не базируется на реквест-респонз

ой, давайте лучше о монадах

потому что есть разные шаблоны программирования. и есть те, которые не базируется на реквест-респонз

ну а телл с таймаутом это как раз и реквест-респонз

так ведь ты и не сломаешь модель акторов своей футуркой. может сломаться только твоя программка, если она вдруг думает, что она является частью актора

ок я не имел ввиду ломать дизайн актор модели, и тут я тоже согласен футура не ломает дизайн, но прогрммку можно сломать - что у чела и случилось

лучше скажите, перестал ли coursier сносить башню идеи?

ну а телл с таймаутом это как раз и реквест-респонз

да нет жеж. неудивительно, что потом люди кричат "не шмогла я в акторы, акторы днище, го в го"

лучше скажите, перестал ли coursier сносить башню идеи?

пользуюсь с очень раннего майлстоуна и все ок

что не так?

да нет жеж. неудивительно, что потом люди кричат "не шмогла я в акторы, акторы днище, го в го"

да почему нет? таймаут есть, значит ожидаем ответ, по сути тот же аск. вот если бы таймаута не было, то было бы другое дело

пользуюсь с очень раннего майлстоуна и все ок

гут

гут

добавил global plugins, отлично все работает

ок я не имел ввиду ломать дизайн актор модели, и тут я тоже согласен футура не ломает дизайн, но прогрммку можно сломать - что у чела и случилось

Ну вот видишь, пришел наконец к тому, что реакция на футурку не является частью акторов.

Ну вот видишь, пришел наконец к тому, что реакция на футурку не является частью акторов.

когда я первый раз упоминал актора, я имел ввиду конкретный инстанс актора а не модель или дизайн акторов. а то что футурка не часть актор модели я и так знал и к этому сейчас не приходил, просто у нас с тобой возникло элементарное недопонимание, и как мне показалось ты решил потыкать меня носом в дизайн на всякий случай если я его вдруг не понимаю, спасибо за заботу :)

да почему нет? таймаут есть, значит ожидаем ответ, по сути тот же аск. вот если бы таймаута не было, то было бы другое дело

Потому что как я написал выше - это будет крайне похоже на реквест-респонз только при определенных условиях. Сейчас накидаю на скасти грубые примеры

все уже сменили пароль на апворке?) тут же кладуфлар удивил https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/

да почему нет? таймаут есть, значит ожидаем ответ, по сути тот же аск. вот если бы таймаута не было, то было бы другое дело

https://scalafiddle.io/sf/aMU66L4/1

опять таки это ведет к брейку "реквест-респонз", потому что ты ручками начинаешь отслеживать флаги. и когда тебе понг придет - без ask это означает, что ты понятия не имеешь на какой пинг он пришел и вобще пришел ли он на пинг

Да, есть такое, поэтому приходится возвращать в response userId что бы знать на какой запрос пришел ответ.

Да, есть такое, поэтому приходится возвращать в response userId что бы знать на какой запрос пришел ответ.

или если ты роутер (или типа того) можешь сделать forward и ответ улетит оригинальному сендеру

https://scalafiddle.io/sf/aMU66L4/1

вообще пример весьма замудренный. какую проблему он решает?

когда я первый раз упоминал актора, я имел ввиду конкретный инстанс актора а не модель или дизайн акторов. а то что футурка не часть актор модели я и так знал и к этому сейчас не приходил, просто у нас с тобой возникло элементарное недопонимание, и как мне показалось ты решил потыкать меня носом в дизайн на всякий случай если я его вдруг не понимаю, спасибо за заботу :)

Нет, изначально я просто уточнил, что реакция на футурку не есть часть акторов. Просто маленькое уточнение, а не противоречие. А потом ты писал всякие забавные вещи, но джунам можно)

Да, есть такое, поэтому приходится возвращать в response userId что бы знать на какой запрос пришел ответ.

Мало того, что это банально неудобно, так это будут только цветочки - весь говно-бойлерплейт только начнет зарождаться на этом месте.

так что если можешь решить проблему через Future/Task или стримы то лучше решай через них

вообще пример весьма замудренный. какую проблему он решает?

Он не решает проблему. Он показывает проблему, что телл+таймаут не равнозначно семантике "рек-респ" в лице аск

вообще пример весьма замудренный. какую проблему он решает?

и это не мудреный пример. Это только пара моментов, которые решаются аском внутри

а зачем делать tell с таймаутом если есть ask?

Tell это истинно акторный подход, он и по remote работает и вобще в этом идея акторов. А ask как уже заметили это не про акторы и нада использовать его редко, когда невозможно/неудобно делать req resp через сообщения

не чаще трех раз в неделю?