Debug недостающих сообщений в Akka

Question

У меня есть следующие архитектуры в данный момент:

нагрузки (Play приложение с основным интерфейсом для испытаний под нагрузкой) -> Шлюз (опрыскивание REST интерфейса для входящих сообщений) -> Processor (Акка приложение, которое работает с MongoDB) -> MongoDB

Все работает нормально, пока количество сообщений, которые я проталкиваю, низок. Однако, когда я пытаюсь подтолкнуть 10000 событий, это будет в конечном итоге на MongoDB в качестве документов, оно останавливается в случайных местах, например, в сообщении 742 или сообщении 982 и ничего не делает после.

Что было бы лучшим способом отладить такие ситуации? На стороне нагрузки я просто нажав трудно в службу REST:

for (i ← 0 until users) workerRouter ! Load(server, i) 

, а затем в workerRouter

WS.url(server + "/track/message").post(Json.toJson(newUser)).map { response => 
    println(response.body) 
    true 
} 

На стороне распыления:

pathPrefix("track") { 
    path("message") { 
    post { 
     entity(as[TrackObj]) { msg => 
     processors ! msg 
     complete("") 
     } 
    } 
    } 
} 

На стороне процессора это просто вставка в коллекцию. Любые предложения о том, с чего начать?

Обновление: Я попытался переместить логику создания сообщений в Gatewat, сделал цикл от 1 до 10000, и он работает нормально. Однако, если спрей и игра включены в трубопровод, он прерывает и случайные места. Любые предложения по отладке в этом случае?

Answer 1

Я переместил приложение для тестирования нагрузки в раму Spray, и теперь он работает как шарм. Поэтому я полагаю, что проблема где-то в пути, который я использовал WS API в рамках Play:

WS.url(server + "/track/message").post(Json.toJson(newUser)).map { response => 
    println(response.body) 
    true 
} 

Проблема resovled но не решена, не будет работать на решение, основанное на Play.

Answer 2

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

Как только наша команда провела 3 месяца (!) При настройке приложения на надежную круглосуточную работу. И все же были ошибки. Затем мы применили метод Model checking (Spin). В течение пары недель мы реализовали модель, которая позволила нам получить надежное приложение. Тем не менее, проверка модели требует немного другого способа мышления, и ее может быть сложно начать.