Только один вариант — отвечать Ack-сообщением. Один из базовых принципов в архитектуре Akka — это location transparency, что значит актор может физически находиться где угодно. Можно не заморачиваться если jvm одна (и то с нюансами, актор может быть мертв, а почта в спец-ящике), но для другого инстанса (особенно где-то на другом хосте или вообще в другом дц) нельзя получить гарантию в принципе. Магия пока не доступна. Если вы соседу через забор камень кините, то пока он вас не обматерит, вы не узнаете результат (соседа нет, камень улетел куда-то дальше, соседа вырубило камнем). Смотрите как на аналог UDP в сетевом стеке. Соорудить из UDP TCP можно, обратно нет.
С тем же успехом можно было написать 10 и 110 крат.
Вместо анализа производительности содержание какого-то маркетингового буклета. Начальные условия систем (наполнение, исторические фрагментации и т.д.) неизвестны. Анализ запросов к БД отсутствует. ПО отличается судя по названиям. «После подготовки и настройки каждого тестового стенда были выполнены серии тренировочных тестов и тюнинг развернутых приложений.» — вообще прекрасно.
У меня жена изматерилась на ваших модераторов. Обязательные поля подсвечены не были, в итоге впервый раз на этом зарезали. Поправила. Потом пошли придирки, что нет конкретики, хотя по её профессии вполне достаточно было для первичной оценки. Несколько часов бессмысленных мытарств. Зато через 12 часов с первой попытки первая редакция прошла. Видать смена другая была.
При первом запуске обязательно требует выбрать браузер по умолчанию, но при этом текущую версию я-браузера выбрать нельзя. Только альфу. Ну и соображает ощутимо долго при любых действиях.
Вопрос глубины знаний технологии и их оценки работодателем. Судя по комментариям к статьям о go, четкого понимания идеологии языка в сообществе еще нет. Как следствие крайне трудно оценить куда приведет проект каждый конкретный разработчик.
В момент популяризации питона в веб-разработке было тоже самое, брали на хорошие оклады людей с малым багажом знаний и почти полным отсутствием опыта. Оценить-то никто толком не мог.
Подобная классификация нужна, ибо часто люди не понимают что смешивают в кучу несвязанные термины. Имхо, проблема данной структуры в названиях. Не все из них отражают суть. Нагрузочное так вообще лучше убрать, чем вбивать HPшную терминологию (потом не отскребешь из мозгов). «Надежность и восстановление после сбоев» называется отказоустойчивостью и имеет место быть как в функциональной части так и в нагрузочной. Нет юнит-тестов, не видно всяких санити и смоуков.
Ну и зубрить это тоже имхо не имеет резона. С опытом само запомнится. Как подсказка отлично.
Все интересно, но только «высокая производительность» не подходит как описание подборки. У вас исключительно работа с большими данными и вопросы связанные с производительностью и масштабированием баз данных.
На parleys.com в принципе много полезного по скале можно найти. Обычно туда же попадают записи выступлений с конференций.
Вместо анализа производительности содержание какого-то маркетингового буклета. Начальные условия систем (наполнение, исторические фрагментации и т.д.) неизвестны. Анализ запросов к БД отсутствует. ПО отличается судя по названиям. «После подготовки и настройки каждого тестового стенда были выполнены серии тренировочных тестов и тюнинг развернутых приложений.» — вообще прекрасно.
В момент популяризации питона в веб-разработке было тоже самое, брали на хорошие оклады людей с малым багажом знаний и почти полным отсутствием опыта. Оценить-то никто толком не мог.
Ну и зубрить это тоже имхо не имеет резона. С опытом само запомнится. Как подсказка отлично.
Там и про материалы написано.