Проверка атома состояния, который обновляется кольцевым обработчиком

Рассмотрите следующий сценарий:

Минимальная загрузочная задача запускает http-сервер:

(boot (serve :handler 'myapp.server/handler
             :port 3000))

(Его можно запустить несколькими способами, здесь можно просто запустить его из сеанса nrepl, например запустить boot repl из терминала)

Обработчик представлен функцией handler внутри пространства имен myapp.server. Соответствующий файл выглядит так:

(ns myapp.server (:require ...))

(defonce server-state (atom {:nr 0}))

(defn handler [req] 
  (prn (swap! server-state update :nr inc))
  {:body "Answer.\n"})

Это работает, каждый раз, когда посещается адрес localhost: 3000, атом обновляется, и новая версия выводится на стандартный вывод внутри repl.

Как атом может быть проверен в любое время?

boot.user=> @myapp.server/server-state

выдает ошибку. (...no such var...)

При попытке сделать то же самое из соединения emacs cider nrepl эта предыдущая попытка всегда показывает начальное значение атома: {:n 0}


ОБНОВЛЕНИЕ

Вот точные шаги, которые я делаю при использовании emacs/cider:

  1. cd каталог проекта
  2. начать emacs
  3. cider-jack-in
  4. (boot (dev))
  5. Ctrl+C+C (чтобы снова получить подсказку.)
  6. Затем регистрируется тестирование с curl: получение ответов + внутри обновленного атома emacs: {:n 1} .. {:n 2} ..
  7. Затем, в ответ: (require 'myapp.server), занимает некоторое время: nil.
  8. наконец: @myapp.server/state --> однако: {:n 0}

person Anton Harald    schedule 12.08.2016    source источник
comment
Вы уверены, что ваш обработчик кольца и ваш repl работают в одном и том же процессе JVM?   -  person Piotrek Bzdyl    schedule 12.08.2016


Ответы (1)


Ваша ошибка (...no such var...), вероятно, возникает из-за того, что вам не требуется пространство имен myapp.server. Попытки увидеть обновления, происходящие с вашим атомом в CIDER REPL, терпят неудачу, вероятно, потому, что ваше кольцевое приложение работает в другом процессе JVM, чем ваш REPL, поэтому REPL видит только начальное значение, поскольку обновления из кольцевого обработчика происходят в другой JVM или оно заключено в отдельный загрузчик классов как он может быть изолирован загрузочным устройством POD.

У вас есть два варианта:

При первом подходе вам, вероятно, потребуется использовать nrepl от boot-clj. вариант. Когда вы настраиваете его для запуска сервера nREPL, вы можете подключиться к нему, используя boot repl -c (при необходимости указав те же координаты, что и для параметров boot-http nrepl) или напрямую из CIDER с помощью cider-connect.

person Piotrek Bzdyl    schedule 12.08.2016
comment
Единственное, что я могу себе представить, это то, что (boot ..) порождает новый процесс JVM. - person Anton Harald; 12.08.2016
comment
Да, это может породить новый процесс JVM. Вы можете проверить список процессов JVM до и после выполнения (boot (dev)). Это также может быть проблемой пути к классам, поскольку он использует POD для изоляции зависимостей задач (github.com/ boot-clj/boot/wiki/Pods). - person Piotrek Bzdyl; 12.08.2016
comment
Ладно, конечно работает, если сервер запускать сразу из репл. Это вариант в некоторых случаях. - person Anton Harald; 12.08.2016
comment
кстати, так как вообще интересно знать: количество JVM все равно после (boot ..) , только что проверил это. - person Anton Harald; 12.08.2016
comment
опция nrepl задачи boot-http очень хорошо подходит для этой цели. Я сделаю это так! - person Anton Harald; 13.08.2016