2010-01-02 4 views
1

Я принимаю около event функции в Nitrogen, the Erlang web framework, в веб-модуле, который запускается, когда вы получаете обратную передачу.Являются ли события всегда одинаковыми в азоте?

Выполняет ли event один и тот же процесс для одного и того же веб-клиента (то есть окна браузера или фрейма).

Я помню хотя бы один случай, когда этого не произошло, но я не могу воспроизвести его.

ответ

3

No, Азотные события запускаются в зависимости от того, какой процесс в настоящее время обрабатывает веб-запрос на азот.

Поскольку Азот представляет собой очень асинхронную структуру, у вас может быть несколько процессов, обрабатывающих несколько событий для одного и того же окна браузера или кадра асинхронно. Это означает, что вы можете очень хорошо иметь разные события, которые обрабатываются отдельными процессами.

+0

Таким образом, кнопка может доставить такое же событие в два раза, и события будут выполняться в различных процессах. Тогда ответ: Нет. Я добавляю «Нет» в начале этого только для ясности, не стесняйтесь удалять его, если этот комментарий показывает, что я неверно истолковал вас. – Pablo

+0

Ответ «Нет» в том смысле, что азот ничего не делает для обеспечения того, чтобы события выполнялись в одном и том же процессе. Однако, если вы найдете http-сервер, который предоставляет такую ​​функцию (и совместим с азотом), она достижима. – Zed

1

Эй, ребята, я обнаружил регистрацию процесса для азота под названием: nprocreg.
Когда вы проверяете папку приложений ( $ NITROGEN_INSTALL_DIR/apps/nprocreg).

В этом приложении процессы могут появляться на нескольких серверах приложений азота даже на нескольких компьютерах. Чтобы поэкспериментировать с этим, запустите 2 узла erlang на двух разных узлах. пинговать их так, чтобы они были связаны. (net_adm:ping(?OTHER_NODE)). Теперь начните азот на обоих узлах erlang. Вы могли бы сначала запустить азот, а затем выполнить ping два узла.
Убедитесь, что два узла азота используют длинные имена i.e [NAME] @IP_ADDRESS в локальной сети.

Теперь, на третьей машине в вашей локальной сети, создайте DNS (сервер имен). Поместите одноименное сопоставление на два разных IP-адреса наших узлов, работающих под азотом. Настройте два компьютера для запуска азота, чтобы убедиться, что они указывают на IP-адрес DNS для DNS-служб (на самом деле делайте это для всех компьютеров в вашей локальной сети).
Вы обнаружите, что когда вы запрашиваете страницу (находящуюся в корне doc обоих приложений азота) с нескольких компьютеров в вашей локальной сети, используя сопоставленное имя в вашем браузере, вы видите, что DNS-сервер выполняет какую-то балансировку нагрузки.
Теперь убедитесь, что страница, которую вы запрашиваете, может показать вам, с какого сервера азота поступает из интерфейса. На этой странице должна быть указана кнопка, которая генерирует событие, которое будет wf:flash(wf:f("Some statement on the interface",[]))
Теперь запросите эту страницу на двух разных компьютерах и обратите внимание на то, где обслуживается каждый. Затем перейдите на один азотный сервер и остановите его.
Когда вы теперь нажимаете на кнопку в браузере, которая получила свою страницу на сервере азота, который мы только что положили, он все еще работает.
Именно поэтому Расти и друзья обнаружили, что если азотные процессы могут регистрироваться в более азотных приложениях, когда они работают за балансировщиком нагрузки, события могут быть перенесены на любое приложение азота в кластере.
Конечно, это хорошо работает, если вы убедитесь, что два приложения на разных машинах имеют одинаковые страницы, модули и конфигурацию путей. Это связано с тем, что функция обратного вызова события может вызвать вызов API базы данных.
Пример балансировки нагрузки с использованием DNS-сервера можно увидеть, когда вы копать 'Google с вашего терминала на Linux или Solaris, как это:

 
dig www.google.com 
Вы увидите, что сервер имен имеет такое же имя, переведенный на несколько Ip адресов. Это обеспечивает доступность всех доменов и обеспечивает некоторый вид балансировки нагрузки
/ [email protected]

Смежные вопросы