Что такое weblogic.socket.Мультиплексор?

Question

Кто-нибудь из вас понимает, для чего weblogic.socket.Используется мультиплексор в WebLogic 8.1?

Часто в дампах потоков я вижу трассировки стека, похожие на это:

"ExecuteThread: '0' for queue: 'weblogic.socket.Muxer'" id=20 idx=0x68 tid=26709 prio=5 alive, in native, blocked, daemon
    -- Blocked trying to get lock: java/lang/String@0x2b673d373c50[fat lock]
    at jrockit/vm/Threads.waitForUnblockSignal()V(Native Method)
    at jrockit/vm/Locks.fatLockBlockOrSpin(Locks.java:1675)[optimized]
    at jrockit/vm/Locks.lockFat(Locks.java:1776)[optimized]
    at jrockit/vm/Locks.monitorEnterSecondStageHard(Locks.java:1312)[optimized]
    at jrockit/vm/Locks.monitorEnterSecondStage(Locks.java:1259)[optimized]
    at jrockit/vm/Locks.monitorEnter(Locks.java:2439)[optimized]
    at weblogic/socket/EPollSocketMuxer.processSockets(EPollSocketMuxer.java:153)
    at weblogic/socket/SocketReaderRequest.run(SocketReaderRequest.java:29)
    at weblogic/socket/SocketReaderRequest.execute(SocketReaderRequest.java:42)
    at weblogic/kernel/ExecuteThread.execute(ExecuteThread.java:145)
    at weblogic/kernel/ExecuteThread.run(ExecuteThread.java:117)
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)
    -- end of trace

Дело не в том, что у меня с этим какие-то проблемы, просто интересно понять:

1) что он делает?
2) может ли это повлиять на какую-либо производительность?

Answer 1

Из документации (http://download.oracle.com/docs/cd/E13222_01/wls/docs100/perform/WLSTuning.html#wp1152246):

WebLogic Server использует программные модули , называемые мультиплексорами, для чтения входящих запросов на сервере и входящих ответов на клиенте.Эти мультиплексоры бывают двух основных типов:мультиплексор Java или собственный мультиплексор.

Мультиплексор Java обладает следующими характеристиками:

• Использует чистую Java для чтения данных из сокетов.
• Это также единственный мультиплексор, доступный для клиентов RMI.
• Блокирует чтение до тех пор, пока не появятся данные для чтения из сокета.Такое поведение плохо масштабируется при наличии большого количества сокетов и / или когда данные поступают на сокеты нечасто .Обычно это не является проблемой для клиентов, но может создать огромное узкое место для сервера.

Встроенные мультиплексоры используют зависящие от платформы собственные двоичные файлы для чтения данных из сокетов.Большинство всех платформ предоставляют некоторый механизм для опроса сокета на предмет данных.Например, системы Unix используют систему опроса, а Архитектура Windows использует порты завершения .Встроенные обеспечивают превосходную масштабируемость, поскольку они реализуют неблокирующую модель потоков.При использовании встроенного мультиплексора сервер создает фиксированное количество потоков , предназначенных для чтения входящих Запросы.BEA рекомендует использовать значение по умолчанию выбрано для Enable Native IO параметр, который позволяет серверу автоматически выбирать подходящий мультиплексор для использования сервером.

Если Enable Native IO параметр не выбран, экземпляр сервера использует исключительно Java muxer.Это может быть приемлемо, если имеется небольшое количество клиентов и скорость, с которой запросы поступают на сервер, довольно высока.В этих условиях мультиплексор Java работает так же хорошо, как и собственный мультиплексор , и устраняет накладные расходы на собственный интерфейс Java (JNI).В отличие от собственных мультиплексоров, количество потоков , используемых для чтения запросов, не фиксировано и настраивается для мультиплексоров Java путем настройки Percent Socket Readers настройка параметров в консоли администрирования .Видишь Изменение количества доступных разъемов Считывателей.В идеале вам следует настроить этот параметр таким образом, чтобы количество потоков было примерно равно количеству удаленных одновременно подключенных клиентов до 50% от общего пула потоков размер.Каждый поток ожидает фиксированное количество времени, пока данные не станут доступными в сокете.Если данные не поступают, поток переходит к следующему сокету.

Тогда, по этим причинам, очевидно, что лучше использовать собственные мультиплексоры.

Здесь, похоже, вы используете встроенный мультиплексор по умолчанию (weblogic.socket.EPollSocketMuxer), а не мультиплексор Java (weblogic.socket.SocketMuxer).

Answer 2

Я нашел эту ссылку Это объяснило ситуацию в значительной степени:

  

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

Answer 3

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

A " muxer " является мультиплексором, который представляет собой механизм для объединения нескольких потоков данных в один канал. Weblogic будет использовать их для обмена данными с самим собой или с другими узлами в кластере. В любое время некоторые из них будут «заблокированы», поскольку им нечего делать.

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