Что такое weblogic.socket.Muxer?

Кто-нибудь из вас понимает, для чего используется weblogic.socket.Muxer в 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/[email protected][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) может ли это повлиять на любую производительность?

Ответ 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-муксер. Эта возможно, приемлемо, если есть небольшой количество клиентов и запросы, которые поступают на сервер, довольно высокая. В этих условиях, Java-мультиплексор выполняет так же, как и собственный мультиплексор и исключить Java Native Интерфейс (JNI). В отличие от родные мультиплексоры, количество потоков используемый для чтения запросов не является фиксированным и настраивается для Java-мультиплексоров настройка Percent Socket Readersпараметр в Консоль администрирования. См. Изменение Число доступных гнезд Читатели. В идеале вы должны настроить этот параметр, чтобы число нити примерно равны числу удаленные одновременно подключенные клиенты до 50% от общего пула потоков размер. Каждый поток ожидает фиксированного количество времени для того, чтобы данные стали доступный в гнезде. Если нет данных прибывает, поток переходит к следующему сокет.

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

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

Ответ 2

Я нашел эту ссылку, которая очень сильно объяснила ситуацию:

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

Ответ 3

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

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

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