Отслеживание иерархии отправителей в Scala акторах

В настоящее время я поддерживаю пару Scala-приложений на основе акторов, и один вопрос, который я постоянно задаю: Кто отправляет это сообщение?

Например, я нахожу кусок кода, который печатает страшное сообщение, которое я нашел в журналах:

case ReportFailedUpdates(stuff) =>
  log("The horror! The horror! " + stuff)
  dieHorribly()

и я хочу узнать, в чем может быть причина. Если бы я не использовал актеров, я мог бы нажать Ctrl+Alt+H (по крайней мере, в Eclipse) и узнать, кто "вызвал" этот "метод" (и кто вызвал то, и кто вызвал это). Что касается актеров, я обнаруживаю, что ищу ! ReportFailedUpdates(, чтобы узнать, какие актеры отправляют это сообщение, затем ищу отправителей сообщения, на которое реагировал актер, и т. д. (и обычно рисуя результат на бумаге). Это имеет два недостатка:

  • Это медленнее, так как Eclipse выполняет текстовый поиск по (потенциально многим) проектам, и мне приходится записывать материал
  • Это не обязательно находит все вхождения, так как, возможно, это было отправлено с !?, или, может быть, кто-то поставил два пробела между ! и ReportFailedUpdates, или, или, или....

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

Есть ли инструменты, которые это делают? Является ли это особенностью ScalaIDE для Eclipse, которую я просто не обнаружил? Если я буду использовать IntelliJ, станет ли моя жизнь лучше?

Обновить

Мой пример может ввести в заблуждение. Речь идет не только о выяснении того, что пошло не так, когда все рушится — я часто делаю это, когда беру в руки новую систему и мне нужно выяснить, как она работает. Похоже, что еще нет инструмента для этого. Думаю, мне придется подумать о том, как вы могли бы начать статически извлекать (и, возможно, визуализировать) граф потока сообщений...


scala tooling actor
person Martin McNulty    schedule 19.01.2012    source источник
comment
Да, IntelliJ сделает вашу жизнь лучше. Я не думаю, что это решает эту проблему, но это круто меняет жизнь :-)   -  person leedm777    schedule 19.01.2012
comment
@dave: Я не могу не согласиться! :)   -  person tenshi    schedule 19.01.2012

Ответы (1)


arrow_upward
0
arrow_downward

Что ж, это довольно сильное желание, и я был бы очень впечатлен, если бы кто-то написал это, но я пока ничего подобного не видел.

Отследить это будет очень сложно, так как нет «стека» для отслеживания. Мне любопытно, почему вы этого не делаете:

case ReportFailedUpdates(stuff) =>
    log("The horror! The horror! %s (sent by %s)".format(stuff, sender))
    dieHorribly()

Это, по крайней мере, дало бы вам текущее звено в цепочке.

Кроме того - я парень Vim, так что извините за мое невежество - разве ваша IDE не имеет лучшего механизма поиска, такого как регулярные выражения?

person Derek Wyatt    schedule 19.01.2012
comment
Это помогает найти отправителя, но как насчет следующего звена в цепочке? Если я не регистрирую отправителя каждый раз, когда сообщение получено, но тогда я просто заменил свою проблему проблемой разбора журнала. Я подозреваю, что невозможно статически определить это с абсолютной уверенностью, но я бы согласился найти вызовы методов отправки (!, !? и др.), где аргументы имеют тот же тип (или подтип) введите под моим курсором. В Eclipse есть регулярные выражения, но тогда поиск снова замедляется (плюс теперь у вас две проблемы). - person Martin McNulty; 19.01.2012
comment
О, я понимаю. Проблема в том, что в асинхронном программировании на основе сообщений нет цепочки. Там нет стека. Я написал много кода Актера, и это никогда не было проблемой, поэтому у вас может быть системная проблема, но кроме этого, единственный простой способ, который я вижу, чтобы получить то, что вы хотите, - это сохранить цепочку в сообщении как он путешествует. Вы можете сохранить отправителя и полученное сообщение, а затем в момент ужасной смерти вы можете сбросить этот стек, который вы накопили. - person Derek Wyatt; 19.01.2012
comment
Вполне возможно, что эти системы структурированы не в самом идиоматичном актерском стиле, но я придерживаюсь этого, если только не хочу рисковать серьезным рефакторингом. Накопление «стека» — довольно хорошая идея — меньше помогает со статикой. Как работает эта система? вопросы, но полезны для отладки. Принимаю ваш ответ, потому что кажется, что то, что я хочу, не существует! Спасибо за вашу помощь :) - person Martin McNulty; 20.01.2012