Ошибки во время работы AggreGate Server

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

Сбой сервера из-за невыполнения проверки данных

Наши новые партнеры и заказчики часто жалуются, что AggreGate Server может дать сбой в случае неправильной конфигурации, и удивляются, почему конфигурация не проверена на  "защиту от неумелого обращения". Тем не менее, отсутствие валидации данных на уровне платформы явно определено стратегией развития платформы.

AggreGate  - инструмент low-code разработки, поэтому платформа должна быть максимально гибкой, чтобы охватить все возможные сценарии применения. Однако, конфигурация платформы, прекрасно подходящая для одного случая, приведет к сбою системы в другом практическом случае.

Например, если мы конфигурируем драйвер устройства базы данных, чтобы синхронизировать его переменную, следом за чем идет сложный SQL запрос с периодом в 10 миллисекунд, AggreGate Server скорее всего даст сбой при попытке выполнить сотню "тяжелых" запросов в секунду. В то же время, мы не можем ограничить минимальный период синхронизации оной секундой (как иногда просят пользователи) потому что, например, для драйвера Modbus довольно типично читать реестры ПЛК каждые несколько миллисекунд. Более того, даже драйвер одной и той же БД может читать переменные и отправлять простые запросы раз в несколько сотен миллисекунд!

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

Идею отсутствия защиты от сбоев можно лучше понять, сравнив ее с разработкой нового ПО с использованием языка объектно-ориентированного программирования. Например, вы можете написать неэффективный и с ошибками код на Java, который даст сбой, "съест" много памяти и места на диске и даже затронет другие приложения на том же хосте. Однако, сама по себе платформа для разработки на Java не ограждает вас от написания подобного кода: это работа архитектора ПО - обеспечить, чтобы все было сделано правильно.

Точно так же архитекторы приложений на AggreGate должны обеспечить соответствие конфигурации AggreGate Server конкретным условиям и ресурсам выполнения. Кроме того, обычно они же реализуют валидацию данных изнутри сервисов и продуктов на базе платформы, тем самым защищая конечных заказчиков и операторов системы от отказа системы в случае простой ошибки ввода данных.

Сервер потребляет слишком много оперативной памяти

Изучите раздел Использование памяти, чтобы понять как настраивается использование памяти сервером AggreGate и как его правильно интерпретировать.

Регистрируется ошибка: "не способен создать новый поток"

Это сообщение означает, что ОС не позволяет виртуальной машине Java создавать новый поток. Существует несколько решений для данной проблемы:

  • Если ваш сервер использует модели или виджеты, запущенные на сервере виртуальной машины, уменьшить количество параллельных привязок, используемых ими.

Ошибка нехватки памяти: Java Heap Space

Эта ошибка означает, что Вашей виртуальной машине Java не хватает памяти. В этом случае следует увеличить максимальную память, доступную JVM.

Ошибка нехватки памяти: Permgen Space

Эта ошибка означает, что Вашей виртуальной машине Java не хватает памяти для хранения загруженных классов. В этом случае следует увеличить значение параметра -XX:MaxPermSize в параметрах загрузчика сервера.

AggreGate Server, запущенный на linux, регистрирует ошибку "java.net.socketexception: Слишком много открытых файлов"

Это происходит, когда AggreGate Server открывает большое количество сокетов, общаясь при этом с подключенными к сети устройствами (например, через протокол SNMP).

Для решения этой проблемы добавьте следующую строку к началу скриптов запуска AggreGate Server (ag_server, %LS_BINARY%_console и %LS_BINARY%_service):

ulimit -n 100000

Эта команда увеличивает лимит открытых файлов, разрешенных для AggreGate Server, до 100000.

Скрипты запуска сервера будут заново созданы во время обновления сервера, поэтому эту инструкцию нужно добавить заново при обновлении сервера.

Консольный вывод AggreGate Server содержит мусор, когда используется неанглийская версия AggreGate

Это может происходить, когда AggreGate Server запущен в консольном режиме, поскольку командный процессор Windows не использует кодирование UTF-8 по умолчанию. Для активации UTF-8 как кодирования по умолчанию:

  • Откройте редактор реестра

  • Пройдите по HKEY_LOCAL_MACHINESoftwareMicrosoftCommand ProcessorAutoRun

  • Создайте параметр AutoRun типа REG_SZ, если он не существует

  • Поменяйте значение параметра AutoRun на chcp 65001

  • Перезапустите AggreGate Server

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

AggreGate Server наследует поведение по умолчанию виртуальной машины Java и разрешает незаполненные IP адреса и имена хостов в возвращаемый адрес localhost (127.0.0.1). Таким образом, если локальная машина может принять подключение на указанный TCP/UDP порт, подключение может быть успешным даже при незаполненном адресе.

"Ошибка подключения к WS API" во время попытки входа через веб-интерфейс

Существует несколько ситуаций, которые могут привести к повреждению сообщений между клиентом WebSocket и сервером, включая несоответствие между расширениями сжатия сервера и клиента. Иногда это может привести к ошибке подключения к WS API Error connect to WS API, что мешает пользователям входить в AggreGate через веб-интерфейс. Решением является отключение сжатия WebSocket в AggreGate Server. Это можно сделать, добавив следующую строку в файл свойств запуска AggreGate Server Launcher Properties file ag_server.vmoptions лаунчера AggreGate Server:

-Dorg.apache.tomcat.websocket.DISABLE_BUILTIN_EXTENSIONS=true

После того как файл ag_server.vmoptions был обновлен, перезапустите сервер.