Аналогичная проблема. Клиент 7.0.1 виснет, обычно в инфраструктуре во время клика на ноде или контейнере.
По совету ИИ собрал дамп во время зависания приложения
"C:\Tools\jdk-25\bin\jcmd.exe" 25328 Thread.print > "%USERPROFILE%\Desktop\nxmc-threads-1.txt"
После анализа дампа ИИ выдает такой вывод:
Что именно зависло
Главный поток main, который обрабатывает события пользовательского интерфейса, находится в состоянии:
java.lang.Thread.State: BLOCKED (on object monitor)
at org.netxms.nxmc.modules.alarms.widgets.AlarmList$4.run(AlarmList.java:353)
- waiting to lock <0x000000070f800000> (a java.util.HashMap)
at org.eclipse.swt.widgets.Display.runTimer(Display.java:4260)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3748)Одновременно фоновый поток JobWorker-2 выполняет обработку списка аварий:
at org.netxms.nxmc.modules.alarms.widgets.AlarmList.filterAndLimit(AlarmList.java:1078)
at org.netxms.nxmc.modules.alarms.widgets.AlarmList$31.run(AlarmList.java:1112)
- locked <0x000000070f800000> (a java.util.HashMap)Обрати внимание: это один и тот же объект HashMap. Фоновый поток JobWorker-2 удерживает его, а главный поток ждёт освобождения. При этом фоновый поток сам ожидает выполнения операции в UI-потоке через Display.syncExec().
Получается взаимная блокировка:
- UI-поток ждёт монитор HashMap, удерживаемый JobWorker-2.
- JobWorker-2 ждёт, пока UI-поток выполнит синхронную операцию syncExec().
- UI-поток не может обработать эту операцию, потому что заблокирован на первом шаге.
Это объясняет, почему окно перестаёт реагировать на клики и почему дампы, снятые с интервалом, практически идентичны. Проблема находится в клиентской обработке списка аварий (AlarmList), а не в создании сетевых объектов на сервере.
Надеюсь это хоть как-то поможет в решении проблемы.