ловчее не создавать каждый раз, если у них нет состояния

но ведь каждый актор обрабатывает свои сообщения последовательно

так, есть еще вопрос: что делает context watch actor ?

для чего этот watch?

ну в доках же все описано

стоить начать с них

Если хранить состояние через var то не важно последовательно или нет. Если менять состояние через context.become то все ок будет

В смысле состояние в var это путь к проблемам

Надо просто почитать доку. Это лучше чем её пересказывать

часто через become неочень удобно

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

о каких потоках идет речь? Там же всё однопоточное?

ну часто надо сделать ассинхронное действие

сделал действие - отослал событие

как еще с var можно огрести, если не в другом потоке?

ну и идеалогически блаблабла

что бы become были синхронными делайте переход отправля актору его новое состояние через self !

если делать что-то внутри фьюч с состоянием - то ты сам себе злобный буратино

если делать что-то внутри фьюч с состоянием - то ты сам себе злобный буратино

+1

ну так то да, только слать результат через self

Добрый вечер. Читаю в свободное время документацию по Akka, на один интересующий вопрос не смог найти ответа: как жизненный цикл акторов можно контроллировать? Можно ли у родительского актора настроить политику вроде "выгружать ребёнка, если он ничего не делал в течение часа" или "выгружать самого старого ребёнка, если количество детей превысило n"?

Насколько я знаю, встроенного механизма именно для этого нет, но это можно реализовать самостоятельно :)

Нет, такое только руками

а какая цель? если просто чтобы в памяти не гадить - можно акторам самим себя прибивать через setReceiveTimeout

В этой лекции упоминался такой способ менеджмента агрегатов https://www.youtube.com/watch?v=fQkKu4tTgCE но в рекламируемом там фреймворке этого по-моему не реализовано (или реализовано, но я пока плохо читаю код на Scala)

Всем привет. Здесь есть кто учился/учится в EPFL (или может пробовал поступить в магистратуру)?

вроде бы в skype чатике есть Дмитрий Петрашко https://github.com/DarkDimius . не знаю есть ли он здесь

Благодарю!

в гиттере точно есть

и в гиттере тоже есть

Всем привет. Здесь есть кто учился/учится в EPFL (или может пробовал поступить в магистратуру)?

потом расскажешь как оно :)

наука + 90 штук в месяц + горный воздух, должно быть отлично!

90 штук чего?

франки, евро, доллары - какая разница?

в год конечно

в месяц?)

ага

у Бурмако в ЖЖ были описаны всякие нюансы учебы

аренда квартиры, бюрократия, что-то ещё такое

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

а смысл? :)

У меня знакой в 33 года уехал в Сингапур

До этого для железок писал что-то

И кстати даже по стипендии

Всем привет, может кто подсказать, стоит ли гасить соединение с клиентом после того как закончил с ним общаться если клиентов может быть достаточно много и при этом общаться с каждым из клиентов возможно придется достаточно часто?

У вас сервер подключается к клиентам?

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

Есть ведь стандрартный подход с таймаутами

Анатолий, в покер играешь?

Анатолий, в покер играешь?

нет

Есть ведь стандрартный подход с таймаутами

а можно узнать как он назыается? или что почитать?

Есть ведь стандрартный подход с таймаутами

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

Да

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

Хм... я думал там будет что-то более хитрое...

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

Хоть с клиента, хоть с сервера, а лучше и оттуда и оттуда.

Хм.... на каждый чих что ли создавать соединение?

Не только ресурсы, еще и количество сокетов :)

@greenhost87 это тож ресурс

@Visteras Зависит от ваших задач

А если необходимо отслеживать определенные события а сервер про клиента сам не знает? Т.е. в итоге получается что сервер должен сообщить о чем-то клиенту а клиент от него взял и закрылся.

Как-то странно получается

сервер не знает про клиента?! о.О

Нет конечно, ведь соединение закрыто, откуда он узнает что у него есть клиент если его фактически нет?

@folexeyy Да, но именно про сокеты чаще всего забывают, что они имеют свойство заканчиваться

ERROR: S client not available

@Visteras ну он был же

пусть ПОМНИТ

вообще оч странные вопросы, непонятные без контекста

опишите задачу

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

@Visteras ну он был же

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

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

в контексте текущего вопроса

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

Хождние сервера К клиенту, крайне странное решение

да задача проста - чатик централизованный, при этом сервер может быть не один а несколько, больше всего наверно похоже как организован jabber

Хождние сервера К клиенту, крайне странное решение

так и я про то же

Толстое приложение, по актору на "клиента" и кластер в пределах локалки ?

Взять джаббер не вариант?

Проще жаббер взять да

Взять джаббер не вариант?

нет, слишком много допиливать на него придется

точно?

точно, начальство любит мечтать :)

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

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

По вашим вопросом вы в муках рожаете велосипед против шерсти

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

иначе потом будет очень больно

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

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

@Visteras это уже очень много

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

вот не знаю такого человека, потому и приходится так "против шерсти" :)

Это уже не тривиальная зачдача, особенно если вам надо синхронизировать сервера

@Visteras поищите в интернете

наймите

вот не знаю такого человека, потому и приходится так "против шерсти" :)

Это rly плохая идея :) сам на этом запарывался

Это уже не тривиальная зачдача, особенно если вам надо синхронизировать сервера

эм.... глупый вопрос, а зачем их синхронизировать?

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

@Visteras оч глупый вопрос да