Существует ли метод «потоковой передачи» на узел ответа HTTP в потоке сообщений IIB? - PullRequest
0 голосов
/ 01 ноября 2019

Я новичок, и у меня есть поток сообщений IIB, который выглядит следующим образом:

Узел ввода HTTP -> Узел чтения файла -> Узел ответа HTTP.

(1) HTTPВходной узел - поток запускается пользователем, инициирующим запрос https. (2) File Read Node - поток сообщений получает файл с нашего ftp-сервера (локальный файловый каталог, имя файла, хост и учетные данные sftp, а также каталог sftp-сервера - все временно жестко закодировано просто для простоты устранения неполадок решения, но в реальной жизни эта информациябудет извлечен из запроса HTTP). (3) HTTP Reply Node - ответ пользователю с содержимым файла, полученного с ftp-сервера.

Проблема заключается в следующем: поток сообщений вызывает дамп кучи "java / lang / OutOfMemoryError", когда узел чтения файловчитает большие файлы (я тестировал, запустив несколько экземпляров потока сообщений с файлом 124 MG).

Справочная информация. Это устаревшее приложение ASP / VBScript, которое было переписано в IIB. Не мной. Но мне было поручено исправить ошибку памяти.

Подробнее: Из чтения я понимаю, почему выделенная память полностью израсходована. Я прочитал все, что мог, для обработки больших сообщений, но поскольку основная цель этого приложения - позволить пользователям получать файлы с нашего ftp-сервера через ** https **, я, кажется, привязан к этому узлу HTTP-ответа и, таким образом, ко всемуфайл должен быть доступен в объекте MBMessageAssembly (и, следовательно, в памяти), когда поток попадает в терминал «in» узла HTTP-ответа.

У меня такой вопрос: существует ли метод для «потоковой передачи» вузел ответа HTTP? Или можно вообще удалить узел HTTP-ответа и сделать SFTP и HTTP-ответ в Java-вычислительном узле (я не могу использовать вычислительный узел / ESQL, поскольку у нас нет лицензии для этого)? Или есть еще идеи?

1 Ответ

0 голосов
/ 07 ноября 2019

Хорошая формулировка проблемы, и спасибо за проделанную работу перед тем, как опубликовать свой вопрос. Основная проблема здесь заключается в том, что IIB предназначен для обработки сообщений, а не (огромных) файлов. Вы можете поэкспериментировать с увеличением размера кучи для всех

  • прослушивателей HTTP (для всего брокера или EG, убедитесь, что настроили правильный).
  • группа выполнения
  • JVM.

Обратите внимание, что IIB не сохраняет само дерево сообщений в куче JVM, даже если вы используете узел JavaCompute для управления им. Но узел FileRead использует JVM, и ему явно требуется больше кучи Java.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...