Jython (WLST) / Python Communication

Question

Я хочу создать ссылку на jython и python. У меня есть приложение django и скрипты Python, которые я использую для внешнего интерфейса и выполняю задачи системного администратора / автоматизации. Я использую Jython для Weblogic 9/10. Я хочу сделать так, чтобы я мог дать системе jython запрос на выполнение. Например, задание A с аргументами a, b, c, а затем возвращать обратно сообщение, когда это было сделано.

Я хочу сделать это, потому что wlst или jython запускаются медленно, и это становится проблемой, когда мне нужно выполнить развертывание или проверить состояние сервера или серверов (до 100 прямо сейчас). Так какой же самый простой способ передать информацию обратно основному скрипту или классу python, сохранив при этом систему jython / (wlst) и легко делиться / делать запросы?

То, как я это делал, - это использование маринованного объекта. Получая все данные, выплевывая их в файл, затем загружая файл обратно в приложение / скрипт python.

Answer 1

Рассматривали ли вы Сельдерей или какую-либо другую стандартную систему сообщений Queue / Broker?django-celery довольно зрелый, хорошо разработанный и специально разработанный для такого рода задач.

Django -> Celery --> Worker Process (always running)
           ^     |-> Worker Process
           |     `-> Worker Process -,
           \______ Job Complete _____/

Основная идея заключается в том, что у вас есть постоянно работающие рабочие процессы (на 1 или более серверах), ожидающие сообщенийвходите. (это могут быть маринованные объекты или JSON или все, что вы хотите).Эти процессы бездействуют, ожидая, пока Celery (и его бэкэнд RabbitMQ) отправит им сообщение / задание.После обработки сообщения / задания уведомление возвращается через посредника и вызывает обратный вызов в django, в котором вы обновляете статус.

Celery - это очередь задач / очередь заданий, основанная на распределенной передаче сообщений.Он ориентирован на работу в реальном времени, но также поддерживает планирование.

Модули выполнения, называемые задачами, выполняются одновременно на одном или нескольких рабочих серверах.Задачи могут выполняться асинхронно (в фоновом режиме) или синхронно (дождитесь готовности).

Answer 2

Для такого рода сообщений мне нравится использовать настоящую независимую от языка систему очередей сообщений, которую можно использовать снова и снова в будущих проектах.Посмотрите на AMQP, можете ли вы справиться с наличием посредника очереди сообщений, управляющего всеми очередями.Или, если вам не нужен сторонний брокер, посмотрите на ZeroMQ.

В обоих случаях вы можете отправлять сообщения, используя очередь в пабе, которая может обрабатывать несколько рабочих в очереди, если это необходимо.Сообщения могут быть либо простыми текстовыми строками http://tnetstrings.org/, либо они могут быть объектами JSON, либо вы можете даже отправлять засоленные объекты Python вместе с кодом для выполнения, если будете осторожны.Лично мне нравится использовать объекты JSON (подмножество JSON) и распаковывать их в Python-диктовки, чтобы использовать их.

Я использовал AMQP и ZeroMQ в системах с примерно 20 взаимодействующими процессами Python.Это работает хорошо, и если вам нужно подключиться к чему-то не-Python, вы обнаружите, что там уже есть модуль AMQP и библиотека ZeroMQ.

Интересное расширение вашего сценария - иметь 3 видарабочих процессов, написанных на Jython, CPython и IronPython.Таким образом, вы можете использовать сторонние модули Java и .NET, а также бинарные модули CPython, такие как lxml.Объедините его с чем-то вроде Redis, чтобы процессы были полностью отделены и при необходимости могли работать на нескольких серверах.Рабочие помещали свои результаты в Redis вместо того, чтобы смешивать систему очередей сообщений с большими сообщениями, чередующимися с маленькими.При необходимости работник может опубликовать сообщение, содержащее ключ Redis, чтобы другой процесс мог получить это значение.

Answer 3

Маринование в порядке, используйте cPickle для эффективности.Однако вы не должны записывать его в файл.Скорее используйте некоторые другие механизмы IPC, такие как сокеты или каналы (например, см. https://stackoverflow.com/search?q=python+named+pipes), которые избегают дисковой нагрузки.