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

Ответ 1

Это зависит. Когда вы отправляете сообщение актеру из неактивного кода, ActorProxy автоматически создается и сохраняется в потоке локально. Это создает потенциальную утечку памяти, хотя и очень маленькую, потому что ActorProxy не будет GC'd, пока поток не будет GC'd. ActorProxy по существу позволяет неактивному потоку во многом вести себя как актер, включая получение сообщения.

Большая проблема заключается в том, что ваш поток управляется, подобно тому, как библиотека актеров управляет потоками, так что то, что представляет собой логический контекст, может в одно время находиться в одном потоке и в другое время находиться в другом потоке. Хорошим примером этого может быть контейнер сервлетов. Ваш логический контекст может быть сервлетом или сеансом, но ActorProxy будет привязан к потоку и, таким образом, разделен между логическими контекстами. Если ваши участники не отвечают на ActorProxy, это не так уж и важно, но если это так, это может привести к проблемам, потому что либо (а) ответы будут потенциально получены неверным контекстом, либо (б) сообщения никогда не принимаются, и, таким образом, ранее упомянутая небольшая утечка становится большой, поскольку почтовые ящики ActorProxies заполняются.

[Изменить] Хм... Кажется, у меня проблемы с чтением вопросов! Окружать его в блоке actor создает новый объект-актер, который будет GC'd правильно, когда он закончится. Имейте в виду, что отправка сообщения в блок-блок означает, что отправка сообщения будет выполнена в новой реакции на другом потоке, а не в потоке, создающем актера.

Ответ 2

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