Задача:
Есть приложение, в котором уже есть некоторые акторы и определено некоторое простое REST API.

TickerActor — актор, срабатывающий раз в секунду и отсылающий задание в LinksActor на чтение очередного url. Это специально сделано так, чтобы нас не забанили за слишком частые запросы.

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

ClientActor — актор, отвечающий за вызов функциональности spray-клиента.

ServerActor — актор, отвечающий за функциональность spray-сервера

Что хотим:
В целом — сделать акторное приложение для краулинга русского раздела википедии.

В частности (я предполагаю, что обходить граф в ширину все умеют):
разовьем интерфейс и поведение LinksActor.
Пусть он:
- хранит очередь известных, но непосещенных путей и множество посещенных
- принимает сообщение AddPaths со списком путей-кандидатов, отбрасывает уже посещенные, а остальные добавляет в очередь и в множество посещенных
- по PickNext берет путь из очереди и шлет Download в ClientActor
- адекватно отвечает на запрос о статистике

Это 5 баллов из 20

- разовьем поведение ClientActor
- получив ответ и убедившись, что это корректный ответ (код 200), пошлем текст в новый ContentActor
- в случае проблем сообщим о них в IssuesActor. Отдельно обработаем ситуации отсутсвия соединения, ситуацию неуспешного кода и неожиданного типа контента. Будем считать, что все кроме text/html для нас неожиданно

Это 5 баллов из 20

- создадим IssuesActor
Пусть у него будет три сообщения на три типа проблем (см. выше). Реакция — логирование (akka-логирование) и подсчет проблем трех типов.

Это 2 балла из 20

- создадим ContentActor
- добавим в проект внешнюю библиотеку bsoup (найдем ее в мавен-репозитории, добавим в build.sbt)
- научимся принимать сообщения от ClientActor
- будем хранить словарь, отображающий путь на сырой html
- с помощью bsoup будем находить ссылки, отбрасывать ссылки, ведущие за пределы индексируемого ресурса и слать сообщение в ClientActor
- при ошибках парсинга информировать IssuesActor. Там появится четвертый тип проблем

Это 5 баллов из 20

- добавим в сервер новый путь - /issues. Ответом будет json, с 4 полями, в каждом из которых количество проблем каждого из 4 типов.

Это 3 балла из 20

Требования и советы:
Нельзя использовать глобальные структуры. Например, завести глобальный ConcurrentHashMap.
Все данные должны быть инкапсулированы в акторы, ответственные за них.
Допускается локальная мутабельность. То есть можно сделать мутабельную структуру и менять ее в акторе.
Конкретные интерфейсы акторов — на ваше усмотрение.
Часто одному актору нужно знать о других акторах.
Это можно решать двумя способами: или указывать акторов-патнеров при инициализации, или передавать ActorRef через сообщение.
Выбор способа — на ваше усмотрение.